Peter33

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.

Make sure that that you set the download source to Microsoft and not to your upstream server. Also make sure that all necessary microsoft URLs can be accessed through your proxy server. Check the ruleengine.log for error details.

OK, turns out that it happens to be a general legacy problem, after i imaged a newer model also in legacy mode. It happens only when the BDE drive in the formatting step is assigned with a drive letter. Ticking the option not to assign the drive letter solves the problem. Cheers Peter

Yes, actually Lenovo provided us with a new BIOS last month, updating the Micro Code regarding the Spectre mess. Both, the latest published (2014) and this Beta update showing the same behavior.