Kelly L. wrote: I have been reading through the Cool Solutions site and have found a lot of really interesting information. One thing that I have noticed is that no one has mentioned anything about file and user rights to install the patches. The user would need admin rights to do the install. In our organization our users only have USER rights. When we push out MS Security patches we elevate all of the user to Admin using the DLU. Once we are finished the distribution we put everyone back to USER.
How is everyone else dealing with this?
OPEN CALL: Share your experiences with Kelly, and we'll send you a t-shirt for your trouble. Ready, set, go!
We do this through the Application explorer. We put the EXE or MSI in our ZENworks app directory. Users have read and file scan rights to the root of this folder. You will also want to make sure the workstations have rights. You can do this by assigning the ZENworks appobject rights. We also have our PCs go to a workstation object when they get imported. We use this to assign remote control and also assign that object rights to the same App ZENworks dir.
I down the patch and then run it by hand, not to snap it but to run it with a /? to see if there is a quit switch and to see if it asks for any info when being installed.
When you create the ZENworks app put the path to the EXE on the run options - applications tab.
Then on the run options- environment tab select Run as unsecure system user.
When you assign the App, assign it users and workstations. Users with enough rights can install it. For users without the rights, the App will use the NAL service to install so the user will not need the rights (as the NAL service has the rights). Under the Rights to Files and Folder tab, make sure you grant the app rights to the dir where you have the patch.
I know you can also point to the MSI file this way. ZENworks 4 and up actually have some nice MSI features but I have not used it as much. Also there is the ZENworks Patch management which automates much of this and helps identify PCs that need patching. I am getting ready to set this up for a client but have no hands-on experience. But I am sure other knowledgeable people will chime in.
We use the Microsoft WSUS service for client patches.
You can set day and time when patches should be installed, and the installation runs even with user rights.
This may sound simple but it works for us.
- First we download all patches into a folder called Security with other folders in there for the date of the patches. Also in the folder is qchain. It is a utility that allows you to chain the patches if there is more than one.
- Next we create a batch file for each version of OS. 5.00 for Win 2000 and 5.01 for Win XP to distinguish the patches. The variable %OS_VERSION% holds that info.
- Next we create a forced-run application with the options to distribute always, reboot never, run application once, and we run it as a secured system user. That way we don't have to change any user rights or add them and take them out of groups.
Hope this helps. We also use a patch management software, PatchLink.
We use a ZENworks app object. The object copies the patch file c:\support\Patches and then runs the patch executable from that folder. We use the "quiet" and "norestart" switches in the case of Microsoft patches (is there any other kind?). This causes the patch to run in the background with no reboot.In Run Options/Environment the "run as secure system user" is selected so the object runs with system-level privileges on the local workstation. I understand system-level privilege is higher than administrator-level privilege. Some patches never require a reboot while others may, and others always require a reboot. We generally do not force workstation reboots (announced or otherwise) during the day.
For various reasons, including patch-required reboots, we use the PowerOff utility to reboot all workstations daily after hours. The PowerOff utility is available for download here. Since we implemented the automatic after-hours reboot we find workstation and deployment issues are greatly reduced.
What we do in our environment is we have Windows Service Update Server
(WSUS) setup. All OS patches are downloaded in the middle of the night and
the workstations download approved patches at their convenience.
Workstation policy is setup for WS to get their patches from the WSUS
server. What we do is approve patches for IT department first (to test) - once
we are happy other divisions are approved. You can have more than one WSUS
server (we do)- the master sends updates to the slaves. Slaves only get master-approved updates; the catch is the slaves will not send out updates until you have approved them on those servers.
WSUS has logging of what patches are installed on which workstations.
Users don't need Admin rights, patches get installed on their own. WSUS
has the ability do MS application patches also if you are interested.
I last used ZENworks Version 2 to push out an application to Windows 2000 users who only had user rights. If memory serves me correctly, the Application Launcher service took on the administrative rights necessary to make file system and registry changes. My update actually involved upgrading an application and making changes to HKEY_Local_Machine registry entries. The users' rights were never changed. NAL did it all for me. I suspect the same will be true when we start using ZENworks 7 (soon!)
Three words: Unsecure System User
Just make sure the workstations have RF access to the installation source files.
Alternatively, if there are Windows servers in your environment, Windows Server Update Services (WSUS) is an incredible product for deploying and monitoring the status of MS patches.
Here at my company we use WSUS (Windows Server Update Services ) It's a free tool from Microsoft (granted it has to be run on a Windows server box.) It's configured using group policies and you can allow non-administrators to install updates. Before we had this setup, we just used NAL objects with unsecure system rights, or secure depending on the patch. You can force-run it, and most times use switches to make it silent.
When we wish to push out a patch we do so by
creating an application object, which, as you will be aware, assumes
administrator rights when running, and set it to force run once against
the workstation objects or groups you want to push it out too.
Hope this helps.
Using a simple application object run in an Unsecure system user context (executable security level), a few variables, distribution rules and a recent version of ZENworks, it's possible to install many types of patches to multiple versions of Windows with minimal rights.
Be familiar with the use of variables as they'll come in handy when managing a large number of app objects while minimizing the need for even more...
Use the line below as a template for setting up the Run path and file name to said patch.
Refer to the vendor's documentation or knowledgebase for details on parameters or other switches to extend the functionality of the install.
Verify the ZENworks Launcher Configuration on the container (e.g. in ConsoleOne) is set to refresh appropriately especially if the app objects are associated to force run. Assuming eDirectory is running well, replicating and resolving in a timely manner, I prefer to cap these settings a couple containers above where the associated user/workstation objects are contained and allow them to flow down to said objects.
Contingent on the application many patches will extract or otherwise work with temp files locally so in those cases you would just need to grant read/file scan rights to the above PATCH folder or wherever complying with local rights management policy is accomplished. These rights could be configured via the app object or directly to the file system beforehand.
If necessary, and if you are familiar with "COM-enabled languages," you can deploy and register the SetACL ActiveX control (or go the easy route and use the executable) calling it to add/remove permissions to local Windows objects (registry, file system, etc.) via before and after launch scripts in the app object.
Documentation is apparently nonexistent for the control but someone was helpful enough to create a library of the available functions.
Finally, Distribution Rules can be set as simply as flagging for the appropriate OS and the date or version on a key file across OSes in the update. I prefer referencing the registry, since a particular file is more likely to be corrupt or otherwise unreliable compared to a value buried deep in a hive, but it's not always feasible.
For example with Microsoft security bulletin MS06-015 you can flag on the OS version >= 5.0.x.x and File Date with %*WinSysDir%\Shell32.dll before 17-Mar-2006. To compensate for time zone and other file system time/date differences, I usually bump back the date a few more days. Just be considerate of the date/version from any previous releases.
We use WSUS to deploy MS-Patches.
For other applications we use the secure/unsecure level in ZENworks.
Both methods work fine with user rights.
For something like this, a purpose-built tool is far more appropriate:
use WSUS. It has built-in support for elevating non-admin users only
for the task of applying the update.
Here are some solutions to install software for users with only user rights.
- Install apps with a workstation which has system rights. You have to import workstations first to be able to do this. Useful for all things which are not important for users but for the workstations like patches.B
Because of the workstation not having drives, you have to use UNC Path. Second point is local administrator as services have problems to access network resources.
To avoid problems first copy all files local to a folder your users have all rights for (e.g. c:\temp).
- You can use runasp which has more possibilities than runas from Microsoft to run programs with adminstrator rights (only local). For this administrator accounts all should have the same password or you have to add one special account with admin rights on all workstations (for e.g INSTALLER). runasp allows you to save login scripts with password as encrypted file so no user is able to see the password from this special account.
- Some, not all, applications are able to run as "system services" or "unsecure system service" which is part of ZENworks applications. Be careful to avoid drive letters. You have to use the UNC path to copy down the files.
- For Windows updates there exists an update server from Microsoft, which is able to distribute patches from a internal server to all workstations. Maybe this will be the easiest way to distribute Microsoft updates without the need to download all patches from internet to the workstations. Further you have control over what is distributed and installed.
I used to download the patches manually, then create ZENworks app objects
for them and set the run level to be either secure or unsecure system user
(admin rights) and force run. This works for doing service packs, and
critical updates, but can be very tedious if you have a lot of them to do.
You can create the rules for OS-specific patches to require that OS, as well
as check either file versions or registry entries to know if the patch is
needed at all from the availabily/Distribution rules. It does work, but it
requires some time and effort. But you don't need to elevate the rights of
the users. Set up a test machine for each OS, with a test user (user
rights) to test your patches before you set them as force run. Also make
sure and use the install options for each patch so you can install silently
with out forcing a reboot. There are afew different sets of options for
various patches, so you may need to check the MS KB docs to know which set
of options to use.
After setting up the 100-machine evaluation of ZPM (ZENworks Patch
Management, which is a great tool!), I talked management into purchasing the
licenses for ZPM. Much easier to manage, and to see which patches are even
necessary. I only wish that it didn't have to run on a Windows server, it
would be so much cleaner if we could run it on NW/OES or SLES.
We used to create a Nal application object with elevated rights for each security patch - it works but you end up with a few Nal applications.
We now using HotfixInstaller - http://www.novell.com/coolsolutions/tools/14452.html
One Nal application for all security patches.
Source paths - You can also use %FILESERVER% in the unc path for the file name so you don't hardcode the server for each site, or you can create a generic local DNS entry at each site, and use that in the unc path which will allow people and PCs to roam and gain access to the local server whereever they are.
We experienced the same problem and this worked.
- Use the Admin Studio product to covert your exe files to an msi.
- Create the nal applications for each msi and chain them together (use UNC paths to point to the msi objects). You can use the environment variables to configure for specific OS versions and file/patch levels.
- Assign the nal applications to the workstation objects (assuming you have your workstations imported into the tree).
If you have imported your workstations into the tree and assigned the apps to the workstation objects, then the ZENworks Workstation Manager will install the msi objects under the SYSTEM scope, negating the rights issue.
We could not get this to work with ZENworks 4.01 but it worked in ZENworks 7.
The other alternative is to purchase a patch management product like Patchlink (available as an OEM under ZENWorks) or use Microsoft's WSUS.
We previously used ZENworks to push out patches but this became tiresome as you had to unpack and put the command line in.
We now use Windows Update Services - a much better product and can be pushed out using ZENworks Group Policies.
The one solution I didn't see anyone mention is the easiest that I have
used. That is to use Novell ZENworks Patch Management (PatchLink) to push out
patches. Users do not need local Administrator rights to install the
patches. Everything is handled by the PatchLink agent that runs as a system-level account. There is a free eval to try. Once you use it, you will never
want to manually push out patches by ZfD again.
We managed to solve a rights problem with a tool called CPAU. We used this program to install our virus scanner by elevating the rights of the install to administrator. The only drawback I found was it worked best if we copied the exe to be installed locally first, where from the file was then easily installed. I've added the batch command below:
copy W:\Algemeen\CPAU\CPAU.exe c:\windows\temp\CPAU.exe
copy W:\Algemeen\Trend\trendnt.exe c:\windows\temp\trendnt.exe
c:\windows\temp\CPAU.exe -u administrator -p xxxxx -profile -cwd c:\windows\temp -ex c:\windows\temp\trendnt.exe -hide
This has worked great for us, and I'm sure we will be using this tool more in the future to solve such irritating installer issues under user rights.
Phillip E. Thomas
We also use Windows Software Update Services, which is a much improved product over the prior version, SUS. Updates are actually installed by the "Automatic Updates" service, not by the user, so no administive rights are required.
Administrators have a few choices about how updates are installed to client PCs, depending on how strict your environment is. Users can be notified before download (and can choose to delay), or patches can be forced to download. Users can be allowed to control when patches are installed, or the installation can be forced at a certain time. If no user is logged onto the system, it is immediately rebooted. If a user is logged on, the administrator can configure whether the logged-on user gets to choose whether to reboot, or the really tough admin can configure the system to reboot five minutes after installation, no matter what!
Some drawbacks to WSUS: PCs are identified to the server by a SusClientID string value in the local system registry, so PCs that are reinstalled, even with the same computer name, will show up multiple times in the WSUS database. This means the WSUS admin has to periodically delete obsolete workstation objects from the console. It also means that computers that are installed using imaging must not have the GUID in the registry. To clean it up, see Microsoft KB article 903262.
WSUS is also limited in what content you can distribute. Patches for a large number of Windows products are available, but Microsoft decides what patches to distribute. Basically, only security updates and so-called "critical updates" are available. However, since some manufacturer drivers and certain service packs are also included, their decisions seem a bit arbitrary. With the older SUS software, you could browse the server and find the patches, pull out the executable files and use them in other ways like distributing through ZENworks. With WSUS the patch files are all stuffed into a database.
For a free download, WSUS is a great product, but not comparable to a full-fledged life-cycle management product like ZENworks. In the specific case of Microsoft patches, it's the easiest way to get the job done.
Here is what we do, for patches and other apps that need admin rights.
Using the NAL icon distribution options, copy the patch and sanur.exe to
%temp%, and create two files (distribution options|test files) also in
%temp% . One file to contain the local admin password and the other to
run the update.
|_msiexec /i "<file>.msi /passive
Using the launch scripts (run before launching) create a batch file in
%temp% that will run the runas command and passing install.bat into the
command window, thus running install.bat with elevated rights. I use a
vbscript to create the initial batch file, as I have had problems
getting the launching batch file in place using other methods. Because
these launch scripts are vbscript so you need to set the script engine
location to wscript.exe and the file extension to .vbs.
set oFso = createobject("scripting.filesystemobject")
set oNetwork = createobject("wscript.network")
ForWrite = 2
sPath = "C:\Docume~1\" & oNetwork.username & "\Locals~1\Temp\"
set sFile = oFso.opentextfile(sPath & "Patch.bat", forwrite, true)
sFile.writeline "@echo off"
sFile.writeline "runas /u:%computername%\administrator " & chr(34) &
"cmd.exe /c " & sPath & "install.bat" & chr(34) & " | " & sPath &
"sanur.exe" & " /i " & sPath & "<password file>.jpg"
With the run after termination launch script, you can delete the files
you don't want to leave behind (ie the password file).
set oShell = createobject("wscript.shell")
sPath = "C:\Docume~1\" & oNetwork.username & "\Locals~1\Temp\"
oFso.deletefile (sPath & "Patch.bat")
oFso.deletefile (sPath & "install.bat")
oFso.deletefile (sPath & "<password file>.jpg")
oFso.deletefile (sPath & "sanur.exe")
You then set the NAL app to run %temp%\patch.bat
Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).
It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.