Peter33

Make sure that your Firewall allows inbound remote management on the DP as well outbound on the MP. Also make sure that your MP computer account is a member of the local admin group on the DP.

This command should work .. WFLASH2x64.exe xxxxxxx.ROM /bb /rsmb /ign /quiet /sccm The Problem is that you actually need a shutdown and not a resboot, which is not supported in SCCM. There is a workaround with a delayed restart command but its not very pretty or reliable. Also the kernel mode driver is using outdated and supported SHA1 signatures. The whole ThinkCentre BIOS update routine is pretty much crap 😀 There is also a problem with HVCI and those outdated signatures, which might cause blue screens under Windows 10 wen you have HVCI avtivated. After all i switched to the UEFI driver updates from https://www.catalog.update.microsoft.com/Search.aspx?q=thinkcentre%20firmware . Problem there is, they are not updated as often as they would be needed to. But they are easy to install and just require a plain old restart. Cheers Peter

(Get-CMApplication -Name 'AppName').DateCreated or even better (Get-CMApplication -Name 'AppName').DateLastModified

Just create the application with only 1 deployment type initially and add the second one after the application object was created. Make sure to give it different name too and you will be fine. 👍

There is no need to mess with the msi. Just create a installer script that uninstalls the application if it is installed and immediatelly reinstalls it. Additionally create a new detection rule for the install date property in the uninstall registry key with a value of >= current datetime.

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.