Peter33

I have seen this when i forgot to enable PXE support and WDS loaded the default image instead.

You could simply create a self extracting 7zip file, then create a SCCM package with the extraction command as program.

Hi Joe, i was going trough the same scenario with our 1803 upgrade and opened a ticket with Microsoft Support regarding the problem. You have to make sure that 64Bit Clients will only receive the x64 upgrade package, which is a size optimzed Version. Unfortunately Microsoft did'nt bother to create a sperate optimized x86 file, because they thought it's not worth the effort, since there are not many Windows 10 32 Bit installations out there. So the first file is a combined Installation for both, 32Bit and 64Bit. Since the ADRs (and SCCM Clients) have no build in logic to deal with this situation i ended up using direct deployments of the x64 file. By the way. Deploying both files to a x64 client will mess up the boot configuration and produce a blue screen after the first reboot. The second Installation run will usually succeed. Anyways. Use a direct deployment instead of the ADR for feature updates and you will be fine.

Jörgen Nilsson has a solution for you https://ccmexec.com/2016/05/installing-applications-dynamically-during-os-using-ad-group/ This is for devic based deployments only though.

Try this line to set the PS Drive. Set-Location "$($SiteCode.Name):" -ErrorAction Stop

Sounds contradicting to me, you clearly got "Prod Servers" as part of value2 in your csv, which is confirmed by the executed query. Anyways, either remove "Prod Servers" from your csv and your script will work, or leave it there and my script will work. 👍

Not sure why you added this line "$newcolname = “Prod Servers: $colname", since you added the Prod Servers part to your csv file already. This way you are duplicating the string which causes the error. Just get rid of this line and change back the variable used in the last line.

Try this import-Module -Name "$(split-path $Env:SMS_ADMIN_UI_PATH)\ConfigurationManager.psd1" -ErrorAction Stop $SiteCode = Get-PSDrive -PSProvider CMSITE -ErrorAction Stop Set-Location "$($SiteCode.Name):" -ErrorAction Stop $Computers = Import-Csv "C:\source.csv" -Delimiter "," Foreach ($Computer in $Computers) { $devname = $Computer.svr_name $colname = $Computer.svc_domainfqdn $ResourceID = (Get-CMDevice -Name $devname -ErrorAction SilentlyContinue).ResourceID Add-CMDeviceCollectionDirectMembershipRule -CollectionName $colname -ResourceId $ResourceID -Verbose -ErrorAction SilentlyContinue }

There is probably some kind of brute force protection built in. You could also just keep yout current TS structure and add the return Code 10 to the success list of the pw reset steps. Then add a reboot after each of those steps. Kinda ugly, but it should work.

You could simply run all 8 steps in single batch file and add "EXIT /B 0" as your last comand line. If you want to make it shiny you can also add an evaluation step after each pw reset line to check if the returned error code is 0 and if so jump to the end of the script.

The error 10 is unfortunately telling a different story. According to the HP white paper this means the password is wrong.

The Get-CMGlobalCondition CMDlet does not return a valid object for the AddRequirement property. This is a known problem and will be addressed in future CB versions. There is a workaround available though. https://social.technet.microsoft.com/Forums/ie/en-US/95e6ad51-0b5c-4d65-9831-753db4e3b557/how-to-add-an-existing-global-condition-to-an-application-deployment-type-via-powershell?forum=configmanagerapps

In combination of ConfigMgr Current Branch (1602 and later) and WSUS 4.0 you can create regular Update Packages and deploy them to your Clients. The ConfigMgr Client got a new feature with 1602 to Service Office 365 Clients. https://docs.microsoft.com/en-us/deployoffice/manage-updates-to-office-365-proplus-with-system-center-configuration-manager#BKMK_Reqs You can still update your Clients via regular UNC path updates if you can't meet the requirements above. I did that before we switched to currrent branch. Just run a weekly scheduled task to download the updates on your server and set the update path on your Clients to the specified UNC path.

Sure, it means whitelisting the required Domains so that the computer account can access them without the proxy authentication. Assuming that the proxy is managed by another department in your Company, you have to open a change request with them. If you are managing the Proxy by yourself you need to check the documentation on how to apply whitelistings.

All Right, log files are always helpful. You need to exclude http://officecdn.microsoft.com from the proxy auhtentication, so the computer account can access it.