K1000 Changing the logon Background
Hello,
I made a script to change change the background image within C:\Windows\System32\oobe\info\backgrounds. When the script verifies if the directory exists, it fails. This directory does exist on the target machine and I can manually adjust and edit the specified directory.
Here is what my script looks like:
Output Log
Running as: SYSTEM Directory does not exist: C:\Windows\System32\oobe\info\backgrounds
Activity Log
Checking if directory exists: C:\Windows\System32\oobe\info\backgrounds
I tested this a few times and it seems that the script can't verify anything past C:\Windows\System32\oobe. I verified the folder properties and it doesn't seem like there is anything that would cause an issue with this script. Any help would be greatly appreciated.
Thanks!
-
I'm experiencing this exact issue. Was a resolution ever found? - jgrotkier 10 years ago
Answers (8)
Can you just move it up to verify? I'm assuming you're adding labels that you want this background on? There's really no reason to verify a directory exists that already exists on every machine.
Are you leaving it running as SYSTEM?
Comments:
-
The script is being run on two test machines, which are part of a label. I tried running the script as both SYSTEM and the Administrator, both seem to fail. When I ran the script without the verification, it did not place the file in the specified directory. I wanted to add in the verification to troubleshoot and noticed it was not verifying a directory that actually did exist. - pregiec 11 years ago
-
What directory was it putting it in if any?
Can you verify you can run this script outside of the Kbox and it copies to this directory? - dugullett 11 years ago
I am able to run the script perfectly fine outside the kbox, which has me stumped. It seems that through kbox I can't edit/create any files/directories in C:\Windows\System32\oobe\info\ as if the kbox does not see the info directory for some reason. I am able to run this script through kbox to change anything within C:\Windows\System32\oobe however.
Comments:
-
can you post the top half of the script page also - SMal.tmcc 11 years ago
Using File Synchronization to acomplish the same task seems to also fail. When trying to download the file to the specified directory it also fails and the file does not appear in the directory.
Comments:
-
The script works in that it copies the file into the C:\Windows\SysWOW64 directory. The file would need to go into the C:\Windows\System32 directory - pregiec 11 years ago
-
that makes sense. You should adding the os bit version to questions in the future, a lot of the times the answer will be different for 32 vs 64 due to syswow64 file and hive entires. - SMal.tmcc 11 years ago
-
glad your good, you also would be better to use xcopy vs copy when creating scripts then you do not need to create and upload a batch file. - SMal.tmcc 11 years ago
After a bit more testing I seemed to have found the problem. It seems that when I specify the following directory:
C:\Windows\System32\oobe\info\backgrounds
The file actually goes to:
C:\Windows\SysWOW64\oobe\info\backgrounds
This would explain why I was not seeing anything within C:\Windows\System32\oobe\info\backgrounds and why the verification failied because \info\backgrounds does not exist in C:\Windows\SysWOW64\oobe.
The question now would be is how would I get the script to run on the desired directory?
Comments:
-
that makes sense. You should adding the os bit version to questions in the future, a lot of the times the answer will be different for 32 vs 64 due to syswow64 file and hive entires. - SMal.tmcc 11 years ago
How should I set up the script if the currecnt one redirects the destination file to SysWOW64 rather than System32? The goal is to have the file transfered over to the system32 directory, but it keeps redirecting it to the SysWOW64 directory.
Any help would be appreciated.
Comments:
-
should be able to use xcopy with the full path instead of variables
do launch a program
use
directory = $(kace_sys_dir)
file = xcopy.exe
parameters = $(KACE_DEPENDENCY_DIR)\BACKGROUNDDEFAULT.jpg C:\Windows\System32\oobe\info\backgrounds /q /y - SMal.tmcc 11 years ago -
When I use the script, it still manages to put the file into SysWOW64 rather than the system32 directory. Would there be any easy way around that? - pregiec 11 years ago
-
Old, I know, but I was running into this problem and came across this thread.
The problem is outlined here: http://www.itninja.com/blog/view/x64-vs-x86-32bit-application-redirects
If you're on a 64-bit system and want to hit c:\Windows\System32, you have to use c:\windows\sysnative - jones948 9 years ago-
Sorry for necro.
As we are currently changing our logon background, I thought it might be useful for those in the same boat.
1. Use a CIR (FileExistsWithMD5(path, MD5value) to check for new logon background. I named it "New Logon Background 2015"
2. Use a file synchronization for the new logon background (C:\Windows\sysnative\oobe\info\backgrounds) *thanks jones948, forgot about this quirk, you reminded me*
3. CIR will show new devices with new background. - Shane_1219 9 years ago
As dugullett indicated can you run the script on its own outside the kbox? Under you username and pwd can you go to that direction and create a file/folder there?
If you can why not just use file synchronizations from the Distribution module. It can create the directory if its not there using your credentials and then copy your image down to that direction. No need to run a script if its just a copy down.