Trying to change a registry key data via bat script
I am having an issue with a batch script that is suppose to change the registry and disable a service. I can get it to work if I run it localy on the computer but as soon as I get Kace to push it down only half on the script works (it will disable the service). When I run it from Kace I use run as local system it will not start the script if I use another option.
here is the bat
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" /v AUOptions /t REG_DWORD /d 1 /f
Answers (5)
Can you please verify the values of
" reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" /v AUOptions /t REG_DWORD /d 1 /f "
I am sure the valude did not change properly, I am currently facing a problem while updating DWARD registry keys with kace , it happen to change they type of the key from DWARD to some thing else.
You can verify the key after running from kace i am sure the key changes from REG_DWORD to REG_ somthing else.
If that is the case then you have to wait, i have log a case with dell kace regarding this problem.
Will update you once i will get the issue solved.
Yeah I have UAC turned off and it is a 64bit OS but when I deploy this company wide it will be on both. I checked to make sure it wasn't changing the key type and its not it stays on DWORD. Its like when Kace runs the bat it thinks it changes the value but skips over it and goes to the next cmd
Comments:
-
In kbox for the x64 registry custom inventory rules and bat files I've had to point to the x64 registry. HKLM64 - ckubaska 12 years ago
-
So in the bat I would change HKEY_LOCAL_MACHINE to HKLM64? - BuckIT 12 years ago
-
You said, "it is a 64bit OS"; I think that's the problem. The KBOX Agent that runs everything KBOX is a 32-bit agent, which means it sees only a 32-bit environment and runs a 32-bit cmd.exe. That 32-bit cmd.exe sees only the 32-bit environment, so what you think is going into HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update is really getting put into HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update . It's easy to look there to find out if that's what's happening. And you can force it to run a 64-bit cmd.exe or reg.exe to solve the problem.
This kind of issue is why I posted a question here, never answered, about the HKLM64 and HKLM32 abbreviations mentioned in a Konference session. - snissen 12 years ago
We are having issues with XP 64bit clients as well. KACE support sent me the following information and it corrected our issues.
It looks like this is a bug with the current version. The bug number for this is AGENT-1891. The reason for this bug is that these versions of Windows do not recognize the Sysnative alias. Fortunately, there is a workaround for this issue.
Workaround:
Microsoft has come out with a hotfix which resolves this issue.
Unfortunately, this will not repair the agent, it will just fix the issue in the Operating system, and the agent will need to be re-installed.
1. Download and install hotfix from: http://support.microsoft.com/kb/942589
2. Reboot when prompted
3. Uninstall the agent
4. Re-install the agent
5. MI using "execute before logon (at machine bootup)" option should now
function correctly.
I hope this helps
Dave