PC-Alex
asked on
Local SYSTEM account, analyzing security settings
I use a W2K server with a group policy, that makes some W2K Prof machines auto-install an msi file.
The W2K prof machine starts up and shows that it starts installing the msi file, but only for a second. The package was not installed.
In the event log you can see an error that says that the source for the package cannot be found. Microsoft describes this case in Q278472. Installing the package by hand works well (being Administrator). The package is located on a network share, on the DC. I have tested several ways when putting the package into group policy, like "\\servername\..." or "\\192.168.1.6\..." etc, but nothing works. I have checked the security credentials for the share, for the subfolder and all in-between folders. "SYSTEM" is there and has always full access. I also included the machine's local account (in security settings, I can browse for objects and selected the computer symbol of the W2K Prof PC), also with full access.
Now I want to test if the local SYSTEM account of the W2K Prof machine has really access to the target folder. But how ?
I know two years ago I managed to open a CMD window by using the task planner (and just saying "start cmd.exe in one minute"), but there must have been an additionyl trick.
Any idea anyone ?
Or, can I change a service on the local machine to run the installation under another account ?
There may be some reason for SYSTEM not being able to have access (english W2K server after initial german W2K server installation, several W2K Prof machines were built with a partition image and then NewSID was used, ...)
The W2K prof machine starts up and shows that it starts installing the msi file, but only for a second. The package was not installed.
In the event log you can see an error that says that the source for the package cannot be found. Microsoft describes this case in Q278472. Installing the package by hand works well (being Administrator). The package is located on a network share, on the DC. I have tested several ways when putting the package into group policy, like "\\servername\..." or "\\192.168.1.6\..." etc, but nothing works. I have checked the security credentials for the share, for the subfolder and all in-between folders. "SYSTEM" is there and has always full access. I also included the machine's local account (in security settings, I can browse for objects and selected the computer symbol of the W2K Prof PC), also with full access.
Now I want to test if the local SYSTEM account of the W2K Prof machine has really access to the target folder. But how ?
I know two years ago I managed to open a CMD window by using the task planner (and just saying "start cmd.exe in one minute"), but there must have been an additionyl trick.
Any idea anyone ?
Or, can I change a service on the local machine to run the installation under another account ?
There may be some reason for SYSTEM not being able to have access (english W2K server after initial german W2K server installation, several W2K Prof machines were built with a partition image and then NewSID was used, ...)
ASKER
Hallo burningmace,
*how* to assign another user I already knew, but *which* service is the one to enforce the group policy (and to install the msi package) is the question. And, of course: What happens to my system if a system service now runs under a different user :-)
Thank you anyway.
*how* to assign another user I already knew, but *which* service is the one to enforce the group policy (and to install the msi package) is the question. And, of course: What happens to my system if a system service now runs under a different user :-)
Thank you anyway.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks oBdA. I can test it tomorrow in the office.
Group policies can be tricky buggers, when things go wrong I just abandon the install-at-boot using msiconfig and "Run As..." (Right Click -> Run As...) the MSI.
I've found it useful in games, especially Max Payne, which seems to hate non-admin accounts.
I've found it useful in games, especially Max Payne, which seems to hate non-admin accounts.
ASKER
Thanks, oBdA, with this command I managed to open a DOS box and find out why it didn't work.
The workstations authenticate on the 2000Server as "ANONYMOUS LOGON". So I could extend the security settings and now the GP - Installations work.
burningmace, where can I apply for being hired ? I'd like my company installing games centrally ;-)
The workstations authenticate on the 2000Server as "ANONYMOUS LOGON". So I could extend the security settings and now the GP - Installations work.
burningmace, where can I apply for being hired ? I'd like my company installing games centrally ;-)
1) Right click the taskbar and click properties
2) Go to the Start Menu tab and click "Customize..."
3) Go to the Advanced tab and scroll all the way to the bottom
4) Under "System Administrative Tools" choose "Display on the All Programs menu and the Start menu"
5) Click OK on both windows.
6) Click Start -> Administrative Tools -> Services
7) Find the service you want and double-click it.
8) Go the the LogOn tab and select "This Account"
9) Use "Browse..." to find the account and type the password into the two boxes.
Hope it's usefull