In the previous three articles in this series, I showed you how to use only scripts to architect and build a large, complex enterprise solution. This final installment in the series gives you the remaining details about the corporate update system, such as information about securing it and advice about using it to its full potential over time.
Securing the Corporate Update System
The corporate update system runs commands on almost every PC in your organization if you so choose. If you implement this solution, you've created a new way of trashing every client on your network just as if you connected to them with administrative privileges and wiped them out. Thus, only legitimate administrators should be able to write to the central script repository. Keep the people with access to a small and manageable group that works together. You should also ensure that the lead systems manager or administrator approves any new script before you install it in the repository and release it into the wild. In addition, you can give everyone read access to the central script repository, but you might prefer to restrict that access to the system account and administrators.
The CUSClientUpdater.job scheduled task on the clients must use an account to run. Figure 1 shows the Task tab of the CUSClientUpdater.job's Properties dialog box. The Run as field must point to a domain administrator—equivalent account. I suggest that you create a central account in Active Directory (AD), give it an obscure password, and set the password to not expire. Then, change the job's Run as property to use that user account when it runs. For details about how to set scheduled-task properties programmatically, see "Scripting Solutions with WSH and COM: Advanced Methods for Task Scheduling," May 2002, http://www.winscriptingsolutions.com, InstantDoc ID 24592, and "Scripting Solutions with WSH and COM: Scheduling Automated Tasks," March 2002, http://www.winscriptingsolutions.com, InstantDoc ID 23935. Or, if you have the Windows XP CD-ROM, you can install the XP support tools and use the schtasks.exe command-line tool described at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/winxppro/proddocs/schtasks.asp to manipulate tasks easily from the command line. You can find more information about the XP support tools at http://www.microsoft.com/windowsxp/home/using/productdoc/en/default.asp?url=/windowsxp/home/using/productdoc/en/ntcmds.asp.
To ensure that the CUSClientUpdater.job account is domain administrator—equivalent, it should be a member of Domain Admins. I'm assuming here that Domain Admins is a member of the Administrators local group on every client on your network, so adding domain users to the Domain Admins group allows control over all the clients as well. This setup is the default way of working for administrators; if your structure is different, you need to follow your local practices for creating on the domain an administrator-equivalent account that you can use.
End users shouldn't be able to modify the corporate update system's client-side components CUSClientUpdater.job, CUSClientUpdater.wsf, and CUSClientLastUpdateNumber.txt. Consequently, you must change the file access permissions for these three files to ensure that only members of the Administrators local group can modify the files. To change file access permissions, you right-click a file, select the Security tab, and make the changes you require. To automate this process, you can use another support tool: the cacls.exe command-line tool described at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/winxppro/proddocs/cacls.asp.
Targeting Selected Clients
In "Scripting a Corporate Update System, Part 3," December 2002, http://www.winscriptingsolutions.com, InstantDoc ID 26969, SimpleCUSClientTargetter.wsf includes the code that Listing 1 shows to set an ADO filter and search for all clients and servers that aren't members of the corporate update system management group. If you want to target only selected clients, add them to a group and modify the ADO filter, as Listing 2 shows. In Listing 2, MYGRP is a constant representing the group.
If you want to specifically target workstations and not servers, you can use an ADO filter such as the one that Listing 3 shows. This filter fetches all computers that aren't domain controllers (DCs—which have a primary group ID value of 515) and whose operatingSystem attribute doesn't end with Server. You can tweak the filter to represent other restrictions—just use ADSI Edit to determine the primary group IDs that you want to include or exclude, then add them to the filter. ADSI Edit is on the Windows 2000 CD-ROM in the \support\tools folder—just use an administrator-equivalent account and click setup.exe in the folder to install the support tools on your client. However, because OS service packs patch and update these tools, you should reinstall any service packs after installing the support tools from the CD-ROM. Or you can go to http://www.microsoft.com/windows2000/downloads/servicepacks, click the link to a service pack, scroll down to the Support Tools link, and click it to find information about which support tools the service pack updates. When Windows .NET Server (Win
.NET Server) 2003 comes out, you can use support tools from this OS version to manage Win2K as well.
Prev. page
[1]
2
3
4
next page 
