Recently our network has been experiencing an issue with our Window 7 workstations on a relatively decent scale (40-60 workstations) where users are prompted with a "Windows is not Genuine" pop-up on login. However, when checking into this, our licenses are fine, and everything on the system appears to function correctly. After working with Microsoft on this, we eventually came to the solution that the files in the WAT folder "C:\Windows\system32\WAT" were corrupt, and the resolution to this was to remove this folder either by deleting it or removing it from this location, and allowing Windows to recreate it. I have found several different ways to accomplish this via command prompt such as
robocopy /e /purge /b C:\Windows\System32\empty C::\Windows\System32\WAT
I have also used
"move C:\Windows\System32\WAT C:\Windows\Temp"
"deltree /y C:\Windows\system32\WAT" and "rmdir /s /q C:\Window\System32\WAT"
Each of these commands work correctly when running from CMD on the workstation as well as when running via the LiveConnect Command Shell within Kaseya.
However when I attempt to build a procedure to run this en masse I find that the procedure log states it runs successfully on each attempt, but it does not appear to do anything on the workstation. I have attempted running these commands as SYSTEM, and have also attempted to run these commands while impersonating the Local Administrator account. Yet each attempt yields the same result.
I am looking for any advice as to a better way to run this command on these workstations or if I am missing a piece of the puzzle in the scripting process. Currently the only functions I am using in Procedures are the "executeShellCommand" and "impersonateUser" functions. is there something additional I am missing?
Your mileage may vary but I had a similar issue with a shell command not working on it's own recently. So instead of running the command directly in Kaseya I created a .bat file with the command in it. Then I used Kaseya to distribute the file to the computer and then execute it.
My procedure uses the executeShellCommand and Execute as System in a 64-bit shell pointing to the location of the .bat. The .bat is just start C:\temp\<executable info>.
But is there a reason you' can't use the deleteDirectory() procedure step in Kaseya to just delete C:\Windows\System32\WAT? I can see it failing if a file is in use so a recursive delete will fail.
Kaseya will post a success because as far as the Kaseya procedure is concerned, it did its job and executed the command. Doesn't really matter what happens after that. (to the script) Have you tried using the deletedirectory() command in Kaseya? I try to use the Kaseya commands as much as possible because it is easier to troubleshoot and you don't have to put a bunch of checks in the script to make sure your cmd commands are doing what you want.
I have attempted using the deleteDirectory() procedure. It does not delete this folder. It could be due to WAT potentially having open files though.
The Procedure Log will tell you if there was an issue if a file was in use. If the commands work in the command prompt I'd say try making a .bat file and point a procedure at the .bat to run it. That's what solved my issue with a command line with arguments that weren't being passed on through Kaseya.
After looking into this further, it seems the reason my commands are failing are do to a permissions issue on these folders. On most on our machines this is an issue on, it appears that TrustedInstaller is denying access to these files. Is there a specific command to ignore system permissions via Kaseya?
Combo Your solution happened to be part of my final solution. As it turned out I was running into multiple compounding issues.
Within the WAT folder existed four files; npWatWeb.dll, WatAdminSvc.exe, WatUX.exe and WatWeb.dll. I found that if the Genuine Windows Message was open on screen, it would lock the WatAdmin and WatUX exes and they could not be moved or deleted. Even when this window was closed, TrustedInstaller restricted permissions on the npWatWeb.dll and WatWeb.dll files, and would not allow you to delete them, but would allow you to move them.
As such, the final solution was to move the entire folder when the Pop-up window was closed to a temp directory "C:\Windows\Temp" in this case. Once moved, a reboot would recreate the WAT folder at the correct location with the correct files. Only after that was created could I delete the old WAT folder.
However, I still encountered issues getting Kaseya to run the script properly. I managed to get it to run by using Combo's solution of %windir% as well as executing it as System in a 64bit shell. If I did not do both, it would not work. The final script I came up with was:
executeCommandShell("move %windir%\system32\wat %windir%\temp", "Execute as System in 64-bit Shell", "All Operating Systems", "Halt on Fail")
and then I was able to run a simple remove directory script after a reboot to clean up.
Thanks for all of the suggestions.