1

I'm trying to deploy a custom background into %windir%\system32\oobe\info\background\backgroundDefault.jpg and have created bat, ps1 files in both Applications and Packages to try and deliver the file, however when run through CM the file and folders are not created and success is reported. Even if the background folder doesn't exist the Detection Method still states it exists.

For the Application method of deployment I tried a File System path detection on File and on Folder. I also tried a custom powershell script for detection. In both cases installation was recorded successful but the files weren't transferred.

Package based installation did the same thing, completed with no errors. I'm pretty confused and search engines aren't helping. When I run the scripts manually with admin access the process works. But SCCM running as System (not in user Context) it repeats the same answer.

Has anyone seen this? I'm stumped. Here is the basic bat and ps1 scripts, the custom detection method was just a PowerShell Test-Path command on the end file.

bat

mkdir c:\windows\system32\oobe\info\backgrounds
xcopy .\backgroundDefault.jpg c:\windows\system32\oobe\info\backgrounds\ /y

ps1

If ((Test-Path "C:\Windows\System32\oobe\info\backgrounds") -eq $False) {New-Item "C:\Windows\System32\oobe\info\backgrounds" -type directory}
If ((Test-Path "C:\Windows\System32\oobe\info\backgrounds\backgroundDefault.jpg") -eq $False) { Copy-Item ".\backgroundDefault.jpg" "C:\Windows\System32\oobe\info\backgrounds" }
HopelessN00b
  • 53,795
  • 33
  • 135
  • 209
Ben Bowman
  • 113
  • 2
  • 3
  • 13

1 Answers1

0

I would use group policy for this, and use Item-Level targeting to hit the machines you want to use. I get wanting to be able to do it in SCCM, but sometimes a different tool does it better.

That being said, I've found success in the past by using a powershell script that did the following:

1)Set the reg key that allows a different background 2)Make a copy of the background and place it with the script 3)Wrapped them up inside a self extracting executable that ran with elevated privliges

The sfx unzipped and ran the script elevated, which set the reg key and overwrote the existing item that was there, which your script doesn't appear to do. So, your powershell script could be hanging up on an invisible prompt that asks you if you want to overwrite the existing file, or not running that command at all because a file exists and Test-Path is returning $true instead of $false.

MDMoore313
  • 5,581
  • 6
  • 36
  • 75
  • Hi BigHomie, thanks for the suggested workaround, but due to the build process using SCCM Task Sequences for both domain joined and offline devices I need to ensure I can deploy the changes via SCCM. With that said I have found a partial solution, the reason the script was not running was due to not qualifying the path for powershell.exe or cmd.exe, changing to powershell.exe -f blah.ps1 allowed it to execute and run the process correctly. However this did not fix the problem with detection. After converting to a Package rather than an App I was able to get it to deploy. – Ben Bowman Feb 11 '15 at 22:54