Jack Dee
asked on
At wit's end with group policy problem. Please HELP!!
I am a Windows 2003 domain admin and have a Group Policy that does not appear to be working.
For those familiar with Trend Micro OfficeScan anti-virus software, I am trying to setup a group policy that will cause the workstation computers to look at the antivirus server for the latest updates and each startup. In addition, if the OfficeScan software is not installed on the workstation machine, the command will start the install. (I'd like to be able to set it for user login, but it requires local admin rights to run. Most domain users are only Power Users on their workstation computers. If I can get it to run on computer startup, I will be happy)
Here is what the .bat script looks like:
--------------------------
@echo off
net use B: /d
net use B: \\10.10.3.70\ofcscan
CD\
B:
autopccp.exe
C:
net use B: /d GOTO END
:END
EXIT
--------------------------
This .bat file runs great on its own when ran on the workstation computer with my account.
The Group Policy is called OfficeScan.User.Policy.
The delegation permissions on this policy are as follows:
Authenticated Users - Read (from Security Filtering)
Domain Admins - Edit settings, delete, modify security
Domain Computers - Read (from Security Filtering)
Enterprise Admins - Domain Admins - Edit settings, delete, modify security
Enterprise Domain Controllers - Read
System - Edit settings, delete, modify security
Under edit, Computer Configuration, Windows Settings, Scripts (Startup/Shutdown), Startup, it points to the scsript location at \\domainname.com\sysvol\do
I have ran RSOP.msc and GPResult. Both show that the GPO is indeed configured to run.
To test, I have uninstalled OfficeScan on a workstation computer that is part of the OU where the group policy is being applied. To rule out policy conflicts, I have even linked the GPO under a seperate test OU with no other GPOs and Blocked Inheritance. A test workstation computers that I am working on has been placed in that OU. "gpupdate /force" has ben ran on that computer and a reboot has been initiated several times. No luck. I have other GPOs for things like font installs that are configured in much the same way, and they work great.
At this point, I am not sure where the problem is and why the .exe in the script will not run on computer startup. Please advise.
For those familiar with Trend Micro OfficeScan anti-virus software, I am trying to setup a group policy that will cause the workstation computers to look at the antivirus server for the latest updates and each startup. In addition, if the OfficeScan software is not installed on the workstation machine, the command will start the install. (I'd like to be able to set it for user login, but it requires local admin rights to run. Most domain users are only Power Users on their workstation computers. If I can get it to run on computer startup, I will be happy)
Here is what the .bat script looks like:
--------------------------
@echo off
net use B: /d
net use B: \\10.10.3.70\ofcscan
CD\
B:
autopccp.exe
C:
net use B: /d GOTO END
:END
EXIT
--------------------------
This .bat file runs great on its own when ran on the workstation computer with my account.
The Group Policy is called OfficeScan.User.Policy.
The delegation permissions on this policy are as follows:
Authenticated Users - Read (from Security Filtering)
Domain Admins - Edit settings, delete, modify security
Domain Computers - Read (from Security Filtering)
Enterprise Admins - Domain Admins - Edit settings, delete, modify security
Enterprise Domain Controllers - Read
System - Edit settings, delete, modify security
Under edit, Computer Configuration, Windows Settings, Scripts (Startup/Shutdown), Startup, it points to the scsript location at \\domainname.com\sysvol\do
I have ran RSOP.msc and GPResult. Both show that the GPO is indeed configured to run.
To test, I have uninstalled OfficeScan on a workstation computer that is part of the OU where the group policy is being applied. To rule out policy conflicts, I have even linked the GPO under a seperate test OU with no other GPOs and Blocked Inheritance. A test workstation computers that I am working on has been placed in that OU. "gpupdate /force" has ben ran on that computer and a reboot has been initiated several times. No luck. I have other GPOs for things like font installs that are configured in much the same way, and they work great.
At this point, I am not sure where the problem is and why the .exe in the script will not run on computer startup. Please advise.
Just as a crazy thought...to verify that the problem is the Group Policy and not the batch file itself or permissions associated with it, have you tried adding the batch file to the user's profile in ADUC and putting a pause in after each line of it so you can see if each line is running or failing? My only thought is that you are an administrative user so if for instance, a certain user is not a local admin for the machine they are logging into, but you need to be a local admin in order to run the exe, you would be able to see that error message in the command window when the script pauses right after it tries to run it. At least then you know that the script is running but not completing for a reason.
This of course, assumes that you are not sure if the problem is the Group Policy itself, or if it is a permissions problem somewhere. If you know it isn't permissions, you can happily disregard this post. :)
Thanks,
Jerod
This of course, assumes that you are not sure if the problem is the Group Policy itself, or if it is a permissions problem somewhere. If you know it isn't permissions, you can happily disregard this post. :)
Thanks,
Jerod
The main problem is the use of "net use"; the startup script runs in the system's security context, and this doesn't have network credentials.
You need to provide an account and password in the "net use" command; an account with read permissions on the share is enough, do NOT use an administrative account or one with write permissions!
And note that you need a line break before the "goto end" (which is actually unnecessary at the moment ...)
if exist b: net use b /delete
net use b: \\10.10.3.70\ofcscan SomePassword /user:SomeDomain\SomeUser
...
net use b: /delete
...
You need to provide an account and password in the "net use" command; an account with read permissions on the share is enough, do NOT use an administrative account or one with write permissions!
And note that you need a line break before the "goto end" (which is actually unnecessary at the moment ...)
if exist b: net use b /delete
net use b: \\10.10.3.70\ofcscan SomePassword /user:SomeDomain\SomeUser
...
net use b: /delete
...
ASKER
Jerod,
I have tried what you have suggested. However, the script does not run or display.
OBdA,
I have a fonts install script that works great. It is setup in much the same way this script is setup and I do not have any account associated with the "net use" command.
I have tried what you have suggested. However, the script does not run or display.
OBdA,
I have a fonts install script that works great. It is setup in much the same way this script is setup and I do not have any account associated with the "net use" command.
If this script is run as a *user* logon script (and I guess it is), then you won't have any problems with it.
Add a ">>C:\Temp\logon.log 2>&1" after the "net use" command and then look at the c:\temp\logon.log file:
net use B: \\10.10.3.70\ofcscan >>C:\Temp\logon.log 2>&1
Add a ">>C:\Temp\logon.log 2>&1" after the "net use" command and then look at the c:\temp\logon.log file:
net use B: \\10.10.3.70\ofcscan >>C:\Temp\logon.log 2>&1
So I understand, you copied the .bat file into C:\WINNT\SYSVOL\sysvol\You
It should have run. That is how we manage our printers (though it's old school, we still do it that way)
Well, if it won't run automagically, can you login as a non-admin user and try to run it from a command prompt as that user? Does it run then and if so, does it successfully complete?
Thanks,
Jerod
It should have run. That is how we manage our printers (though it's old school, we still do it that way)
Well, if it won't run automagically, can you login as a non-admin user and try to run it from a command prompt as that user? Does it run then and if so, does it successfully complete?
Thanks,
Jerod
ASKER
After loggin in as a non-admin user, I try to run the script. It starts to run until it gets to the .exe portion of the script and tells me that I need to have administrator privileges on the computer (as stated in original post). Therefore, I do not think my script is the problem.
I would like to try to get it to run on computer startup instead of user login so I do not have to worry about local admin rights.
With "this script", I was refering to your "fonts install" script.
For the antivirus software, you will need a startup script, and you will need an account with network credentials.
For the antivirus software, you will need a startup script, and you will need an account with network credentials.
Short of making the user a local admin on their machine, I don't know how you would get this to run then since it is permissions and not Group Policy or an error in the script that is getting in the way.
If you get the "must be an admin" error from running the script by hand, it is also not going to run as a GPO.
Though not ideal, another way to do this would be through a scheduled task where you could set the task to run as a domain admin. The user wouldn't need the pw or have access to it for that matter since you would set this up on a machine by machine basis.
Again, far from ideal, but being that the exe can only run as a local admin, I don't know what other options you might have.
Good luck,
Jerod
If you get the "must be an admin" error from running the script by hand, it is also not going to run as a GPO.
Though not ideal, another way to do this would be through a scheduled task where you could set the task to run as a domain admin. The user wouldn't need the pw or have access to it for that matter since you would set this up on a machine by machine basis.
Again, far from ideal, but being that the exe can only run as a local admin, I don't know what other options you might have.
Good luck,
Jerod
ASKER
Hmm! Let's forget about the fonts script that works well. How about running the script like this, without mapping a network drive:
@echo off
\\10.10.3.70\ofcscan\autop
end
I have tried this way also, and it does not work. So is there no way to run it before login at computer startup?
If not, I tried this:
\\10.10.3.70\ofcscan\autop
and it did not work. Is there a typo in that.
Thanks.
@echo off
\\10.10.3.70\ofcscan\autop
end
I have tried this way also, and it does not work. So is there no way to run it before login at computer startup?
If not, I tried this:
\\10.10.3.70\ofcscan\autop
and it did not work. Is there a typo in that.
Thanks.
Why not just create a file path on the computer section of the machine such as %SystemDrive%\ofcscan\ and add the "domain users" to the security permissions so they have read/write/modify access. I do this quite frequently with certain programs that only require a explicit path.
Have you tried to create an administrator install for it also?
\\10.10.3.70\ofcscan\autop
Save the installation to a network path and point your computer or login script to that .MSI or .EXE file.
That should fix the problem. If it won't run on the computer then just assign the package via the software applications in the group policy. I just use login scripts and startup scripts for setting registry permissions, file path permissions and mapping drives, printers and such. All applications that are needed I deploy using GPO's.
Kevin
Have you tried to create an administrator install for it also?
\\10.10.3.70\ofcscan\autop
Save the installation to a network path and point your computer or login script to that .MSI or .EXE file.
That should fix the problem. If it won't run on the computer then just assign the package via the software applications in the group policy. I just use login scripts and startup scripts for setting registry permissions, file path permissions and mapping drives, printers and such. All applications that are needed I deploy using GPO's.
Kevin
When I say file path on the machine, i'm talking about the computer section/windows settings/file section. Add the path there and give domain users access to write/modify or whatever. If you want to get around the admin rights to install either do an administrative installation or set the computer and user section to always install with elevated priviliges.
Kevin
Kevin
Whether with or without mapped drive, a network connection requires authentication.
If you don't want to map a drive letter, you need to establish a secure channel first:
net use \\10.10.3.70\ipc$ SomePassword /user:SomeDomain\SomeUser
\\10.10.3.70\ofcscan\autop
...
Then again, it should work as well if you add the computer account(s) (actually, a group to which you add the comuter accounts) to the share (if not shared for Everyone) and NTFS permissions on the shared folder.
If you don't want to map a drive letter, you need to establish a secure channel first:
net use \\10.10.3.70\ipc$ SomePassword /user:SomeDomain\SomeUser
\\10.10.3.70\ofcscan\autop
...
Then again, it should work as well if you add the computer account(s) (actually, a group to which you add the comuter accounts) to the share (if not shared for Everyone) and NTFS permissions on the shared folder.
ASKER
oBdA,
You may be on to something. To test the script itself before I apply it to a GPO, I ran the .bat file while logged in as a regular user. Here are the results.
"net use \\10.10.3.70\ipc$ SomePassword /user:SomeDomain\SomeUser
The command completed successfully.
\\10.10.3.70\ofcscan\autop
Auto Setup Program V7.0
Copyright Trend Micro, Inc.
1998-2005
(in pop-up: "Error. To install/uninstall the OfficeScan client, you must have administrator privileges to this computer.)"
Everyone has the following access to the share:
Read & Execute
List Folder Contents
Read
Kshays,
What you are suggesting will not work, because the .exe has to be run from the server share. In addition, Group Policy will only let you use .MSI files for software installs and NOT .exe files. This is the reason that I have a script setup.
I've done it many times. The \\10.10.3.70\ofcscan\autop
Group Policy will not just limit you to MSI files. You can use .ZAP files as well. I prefer MSI though.
After the administrative installation and if it did create a MSI file then just deploy the programs MSI file from the shared folder on the network server through GP pointing to the .MSI file. If it didn't create an MSI file then you can also use WinInstallLE to take a snapshot of your system with the "discover.exe" program and then run the setup with administrative privileges and then take a snapshot of the system afterwords. This will create and package an EXE program into an MSI for you to copy to a network shared folder to then publish or assign through GP.
Kshays
Group Policy will not just limit you to MSI files. You can use .ZAP files as well. I prefer MSI though.
After the administrative installation and if it did create a MSI file then just deploy the programs MSI file from the shared folder on the network server through GP pointing to the .MSI file. If it didn't create an MSI file then you can also use WinInstallLE to take a snapshot of your system with the "discover.exe" program and then run the setup with administrative privileges and then take a snapshot of the system afterwords. This will create and package an EXE program into an MSI for you to copy to a network shared folder to then publish or assign through GP.
Kshays
ASKER
kshays,
Let me make sure I understand clearly what you are saying. If I run "\\10.10.3.70\ofcscan\auto
I agree, if I had a .MSI file, this would be much easier. I have deployed software though .MSI files in the past, but never knew how to covert .EXE files to .MSI. That's why I had to write scripts instead.
Let me make sure I understand clearly what you are saying. If I run "\\10.10.3.70\ofcscan\auto
I agree, if I had a .MSI file, this would be much easier. I have deployed software though .MSI files in the past, but never knew how to covert .EXE files to .MSI. That's why I had to write scripts instead.
I believe it should. I just deployed office 2003 this way 2 days ago.
If you install WinInstallLE which is included in the support tools on the windows 2000 server cd's and use UNC pathnames then you can convert .exe into .msi files used to deploy via GP.
I use Virtual PC 2004 to create my deployed packages. I always use a clean os of windows xp. So after I install and package an exe into an MSI file I just delete the virtual server and copy my template VS files into the folder again and then just assign an existing VS.
Run the discover.exe from the run command \\servername\pathname\disc
You select which drives you want to monitor and it discovers the settings. You are asked to run an application. Use UNC paths such as \\servername\path\filename
it will then install.
Now to do the after snapshot. Just use the run command and point to discover.exe again and it will prompt you to take an after snapshot. After it's done you might get warnings such as a path name such as c:\ and not a UNC path, don't worry. The folder with the MSI is in the shared WinInstallLE folder that you shared, just copy this folder to the network share and deploy the app through GP.
Did any of that make any sense?
kshays
If you install WinInstallLE which is included in the support tools on the windows 2000 server cd's and use UNC pathnames then you can convert .exe into .msi files used to deploy via GP.
I use Virtual PC 2004 to create my deployed packages. I always use a clean os of windows xp. So after I install and package an exe into an MSI file I just delete the virtual server and copy my template VS files into the folder again and then just assign an existing VS.
Run the discover.exe from the run command \\servername\pathname\disc
You select which drives you want to monitor and it discovers the settings. You are asked to run an application. Use UNC paths such as \\servername\path\filename
it will then install.
Now to do the after snapshot. Just use the run command and point to discover.exe again and it will prompt you to take an after snapshot. After it's done you might get warnings such as a path name such as c:\ and not a UNC path, don't worry. The folder with the MSI is in the shared WinInstallLE folder that you shared, just copy this folder to the network share and deploy the app through GP.
Did any of that make any sense?
kshays
ASKER
Nope. "\\10.10.3.70\ofcscan\auto
Since I can't seem to get the .exe to work on comuter startup and it has to be done with an admin account is there a way to use the runas command from the command prompt?
Since I can't seem to get the .exe to work on comuter startup and it has to be done with an admin account is there a way to use the runas command from the command prompt?
http://support.microsoft.com/default.aspx?scid=KB;en-us;322906&
http://support.microsoft.com/?kbid=301634
http://www.windowsitpro.com/Articles/Index.cfm?ArticleID=7899
If you don't have a dedicated machine to create the packages then i wouldn't do it then. I would really look into virtual pc 2004 though. It's a very handy way to create msi packages from exe's and another very good way to test things before rolling them out to your network.
kevin
http://support.microsoft.com/?kbid=301634
http://www.windowsitpro.com/Articles/Index.cfm?ArticleID=7899
If you don't have a dedicated machine to create the packages then i wouldn't do it then. I would really look into virtual pc 2004 though. It's a very handy way to create msi packages from exe's and another very good way to test things before rolling them out to your network.
kevin
You should be able to install this as a computer startup (not a user logon) script in a GPO as you planned at first.
You will not need an administrative account for that.
All you need is the proper network credentials. There are two possibilities to achieve this:
* Use a regular user account with (only) Read permissions to establish the mapped drive/IPC connection as described above (this account does NOT, should NOT, and may NOT have administrative permissions on the share or the machine!)
* Add the *computer* accounts to which you want to assign the GPO to the (share, if applicable, and) NTFS permissions of the folder where the installation files are stored; again, Read permissions will be enough.
If you let your current script run as a computer startup and log what's happening, as I suggested above, you will find that the computer account does not have the necessary permissions to connect to the share:
@echo off
set LogFile=C:\temp\ofcscan.lo
if exist "%LogFile%" del "%LogFile%"
if exist B: net use B: /delete
net use B: \\10.10.3.70\ofcscan >>"%LogFile%" 2>&1
B:
cd \
autopccp.exe
C:
net use B: /delete
If you now map drive B: with a user account, or add the computer account to the folder permissions, the script will be able to connect and the installation will be run.
You will not need an administrative account for that.
All you need is the proper network credentials. There are two possibilities to achieve this:
* Use a regular user account with (only) Read permissions to establish the mapped drive/IPC connection as described above (this account does NOT, should NOT, and may NOT have administrative permissions on the share or the machine!)
* Add the *computer* accounts to which you want to assign the GPO to the (share, if applicable, and) NTFS permissions of the folder where the installation files are stored; again, Read permissions will be enough.
If you let your current script run as a computer startup and log what's happening, as I suggested above, you will find that the computer account does not have the necessary permissions to connect to the share:
@echo off
set LogFile=C:\temp\ofcscan.lo
if exist "%LogFile%" del "%LogFile%"
if exist B: net use B: /delete
net use B: \\10.10.3.70\ofcscan >>"%LogFile%" 2>&1
B:
cd \
autopccp.exe
C:
net use B: /delete
If you now map drive B: with a user account, or add the computer account to the folder permissions, the script will be able to connect and the installation will be run.
ASKER
oBdA,
Instead of adding each computer account to the list of NTFS permissions of the folder where the installation files are stored, wouldn't it be enought to just add Domain Computers to that list instead?
Instead of adding each computer account to the list of NTFS permissions of the folder where the installation files are stored, wouldn't it be enought to just add Domain Computers to that list instead?
In general, you should never add single accounts to an ACL (apart from home directories); always use groups. In your case, adding the domain computers should of course work.
I just happened upon this question... and in reading everything over I am wondering why you are attempting to do this from the client side.
First, what version of OfficeScan do you have? Generally, when deploying it from the server you can configure the server to "notify" each client to receive the updates... and then they are pushed out automatically from your server.
In your TrendMicro OfficeScan administrative console, go to Updates > Client Deployment > Automatic Deployment and then configure it accordingly.
I am assuming here that you have a cleint/server installation of OfficeScan, and if you don't you probably should since your problem seems to require it.
Jeff
TechSoEasy
First, what version of OfficeScan do you have? Generally, when deploying it from the server you can configure the server to "notify" each client to receive the updates... and then they are pushed out automatically from your server.
In your TrendMicro OfficeScan administrative console, go to Updates > Client Deployment > Automatic Deployment and then configure it accordingly.
I am assuming here that you have a cleint/server installation of OfficeScan, and if you don't you probably should since your problem seems to require it.
Jeff
TechSoEasy
ASKER
TechSoEasy,
We don't want to push updates out during the middle of the day. Some people shut down their computers before they leave work. Therefore, if we have a computer startup option, we hit everyone from both ends.
Just a little update for everyone else:
I could never get the script to work correctly, even after correctly adding Domain Computers to the list of NTFS permissions on the folder where the installation files are stored. Thus, I researched several different types of software that can create MSI packages, and have decided to go with WinINSTALL LE (http://www.ondemandsoftware.com/PurchaseLE.asp). The only minor problem I have, is the packages were created with the demo version of the software and I had to recreate them with the registered version of the software. Those that got the demo packaged pushed to them via GPO need to have it uninstalled/reinstalled with the registered version.
We don't want to push updates out during the middle of the day. Some people shut down their computers before they leave work. Therefore, if we have a computer startup option, we hit everyone from both ends.
Just a little update for everyone else:
I could never get the script to work correctly, even after correctly adding Domain Computers to the list of NTFS permissions on the folder where the installation files are stored. Thus, I researched several different types of software that can create MSI packages, and have decided to go with WinINSTALL LE (http://www.ondemandsoftware.com/PurchaseLE.asp). The only minor problem I have, is the packages were created with the demo version of the software and I had to recreate them with the registered version of the software. Those that got the demo packaged pushed to them via GPO need to have it uninstalled/reinstalled with the registered version.
Demo version of WinInstallLE? It comes with windows 2000 support tools on the cd. Or at least that's the one i'm using and it's the full version. You can always use GP to deploy the new application within the same OU and then use it to upgrade the demo package. Force a uninstall of the demo package when you set the new package to upgrade it and it shouldn't be a problem then.
kshays
kshays
You don't have to push them out in the middle of the day... TrendMicro allows for "Event-triggered" deployment with this option
"Deploy to clients (For OfficeScan clients only and excluding roaming clients) when they are restarted."
But in reality, I don't understand why you wouldn't want to push out the updates in the middle of the day. They are fairly small and usually contain less data than a user opening an email message. The beauty of TrendMicro's suite is that it updates hourly... and in the kind of environment we operate in where viruses can be transmitted within a few hours around the world, then this seems to be a rather nice feature.
However even if you don't want to do the hourly update... a once daily automatic update generally won't affect a user's environment in a manner that they would even notice.
Jeff
TechSoEasy
"Deploy to clients (For OfficeScan clients only and excluding roaming clients) when they are restarted."
But in reality, I don't understand why you wouldn't want to push out the updates in the middle of the day. They are fairly small and usually contain less data than a user opening an email message. The beauty of TrendMicro's suite is that it updates hourly... and in the kind of environment we operate in where viruses can be transmitted within a few hours around the world, then this seems to be a rather nice feature.
However even if you don't want to do the hourly update... a once daily automatic update generally won't affect a user's environment in a manner that they would even notice.
Jeff
TechSoEasy
P. S. I forgot to mention the Login Script utility included with Trend Micro... look under Administrative Tools in the OfficeScan Management Console. It will do exactly what you are seeking... updates computers as they log into the network.
It may seem that I'm pointing you away from Group Policy... which I am... even though I'm a huge fan of GP, there are some things which are better accomplished elsewhere... and this is one of them.
Jeff
TechSoEasy
It may seem that I'm pointing you away from Group Policy... which I am... even though I'm a huge fan of GP, there are some things which are better accomplished elsewhere... and this is one of them.
Jeff
TechSoEasy
ASKER
Ok. I will check that. Thanks.
ASKER
I checked on the Trend Login Script utility. It only lets you do AutoPcc.exe. It will not let you do AutoPccP.exe. The difference between the two is AutoPcc.exe only checks for update. AUtoPccP.exe checks the whole client, and if the client is not installed it installs it.
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
no problem! :-)
ASKER