Johan Arwidmark has published some undocumented unattend.txt entries for unattended Windows installations.
Scripting changes to resource permissions in Windows
Earlier today, I needed to include some registry permissions changes within a command line script that I was writing. Microsoft knowledge base article 245031 discusses a method using the regini.exe
resource kit tool for Windows NT 4.0; however, for Windows 2000, XP and Server 2003 there is the SubInACL utility (subinacl.exe
) which is far more powerful and much easier to use, enabling administrators to obtain security information about files, registry keys, and services, and transfer this information from user to user, from local or global group to group, and from domain to domain.
Disabling the Configure Your Server Wizard
As useful as it may be for some administrators, I don’t want the Configure Your Server Wizard to appear each time I log on to one of my servers. Microsoft knowledge base article 289080 details a quick registry change to prevent the wizard from starting automatically when new users log on to the computer. Of course, it is also possible to select the checkbox not to display the page at logon, but this registry key is useful for setting via a group policy, or as part of an unattended build process.
Building a Windows cluster using VMware
Over the last few days, I’ve been testing a Windows cluster in a virtual environment. Of course, the whole point of a cluster is a highly available system running on specialised hardware, but for test purposes a virtual environment can be really handy.
It’s a bit tricky, but it works! The information on how to achieve this is contained in two TechRepublic articles by Steven Warren:
Configuring DHCP option 60 for PXE clients
I’m currently working to implement a standard operating environment (SOE) for a client’s server infrastructure, using their preferred deployment platform – the HP ProLiant Essentials Rapid Deployment Pack (RDP), which is based on software provided by Altiris and is effectively a wrapper around the standard unattended build process, but uses the Altiris server instead of Microsoft’s Remote Installation Services (RIS).
According to HP’s implementing RDP and PXE in an enterprise network environment technology brief, when DHCP and Altiris Express are installed on the same server, DHCP will automatically be configured with option 60, which tells the client to make a boot information negotiation layer (BINL) request to the same server to retrieve boot information; however we were placed in a situation where DHCP option 60 needed to be configured manually.
I found the instructions for configuring advanced DHCP options on the website for a competitive product, Rembo Auto-Deploy. For NT DHCP servers, the new client class string option with an identifier of 60
can be added through the normal DHCP server user interface and then configured as a scope option with a value of PXEClient
; however for Windows 2000 servers, the option is not present in the graphical user interface and consequently it is necessary to use the netsh
command to enter the following commands:
dhcp server \\servername
add optiondef 60 PXEClient STRING 0 comment="Option added for PXE support"
set optionvalue 60 STRING PXEClient
show optionvalue all
exit
(dhcp server \\servername
can be replaced with dhcp server serveripaddress
).
Troubleshooting SUS
For anyone having difficulty diagnosing issues with Microsoft Software Update Services (SUS), I’ve produced a SUS troubleshooter diagram. In addition, the following resources may be useful:
- SUSServer.com.
- SUS statistics report (for analysing IIS logs).
Overview of Microsoft Software Update Services
I’ve spent the last few days working on a Microsoft Software Update Services (SUS) proof of concept for a client. In my last job, I implemented a hierarchy of SUS servers across Europe, to manage our Microsoft patch distribution. The system works – but it is a v1.0 product, and is somewhat limited in its management capabilities (for example, if one group of computers needs a different level of patching, then a separate SUS server must be used).
Introduction to SUS
SUS is a security toolkit component born out of the Microsoft Strategic Technology Protection Program (STPP), designed to help Microsoft customers help protect themselves after a number of widespread worms exploited vulnerabilities in Microsoft software. SUS enables administrators to quickly and reliably deploy the latest critical updates and security updates to Windows 2000 and Windows Server 2003-based servers, as well as to desktop computers running Windows 2000 Professional or Windows XP Professional.
In addition to critical and security updates, SUS now provides Windows service packs. SUS can be used to deliver Windows XP SP1, Windows 2000 SP4, and all future service packs for Windows 2000, Windows XP, and the Windows Server 2003 family of products.
How does SUS work?
SUS uses the automatic updates feature in Windows 2000 (SP3 or later), Windows XP (SP1 or later) and Windows Server 2003, but whereas normally, automatic updates are pulled from MicrosoftÂ’s Windows Update servers, SUS allows update requests to be serviced from internal servers.
Each SUS server can be configured to pull updates from the Microsoft Windows Update servers, or from other SUS servers within the organisation, allowing a hierarchy of servers to be established. Once downloaded, updates have to be approved by an administrator before they are released to clients. Approved updates are then pushed to clients and installed according to settings defined in an Active Directory group policy object (GPO) .
An interactive simulation of SUS is available on the Microsoft web site.
Client-side features
The client is based on the Windows automatic updates technology but with significant enhancements for improved manageability. Client-side features include:
- Guaranteed installation of approved updates: administrators can configure automatic updates to automatically download updates and schedule their installation for a specified time. If the computer is turned off at that time, the updates can be installed as soon as the computer is turned on.
- Scheduled installation options: administrators can be allowed to download and install updates manually. All other users are prevented from tampering with the installation of updates.
- Built-in security: before installing a downloaded update, automatic updates verifies that Microsoft has digitally signed the files.
- Accurate detection of necessary updates: the same technologies used for the Windows Update website scan a particular system and determine which updates are applicable.
- Background downloads: the background intelligent transfer service (BITS) – a bandwidth-throttling technology – is used to download updates. Because this technology uses only idle bandwidth, downloads do not interfere with other network activity.
- Chained installation: Windows update technologies are used to chain downloaded updates such that, if multiple updates are being installed and one or more of them requires a restart, they are installed together and a single restart requested.
- Manageability: within an Active Directory environment, an administrator can configure the behaviour of updates using group policy. Otherwise, an administrator can remotely configure automatic updates using registry keys through the use of a logon script or similar mechanism.
- Multi-language support: the client is supported on localised versions of Windows.
Server-side features
The SUS server service is based on the same technology used on the public Windows Update website that has been servicing Windows customers since 1998. Server-side features include:
- Windows critical updates, security updates, and service packs: SUS can be used to distribute Windows critical updates, security updates, and service packs for Windows 2000, Windows XP, and Windows Server 2003.
- Built-in security: the administrative pages are restricted to local administrators on the computer that hosts the updates. The synchronisation validates the digital certificates on any downloads to the update server. If the certificates are not from Microsoft, the packages are deleted.
- Selective content approval: updates synchronised to an SUS server are not made automatically available to the computers that have been configured to receive updates from that server. The administrator approves the updates before they are made available for download. This allows the administrator to test the packages before deploying them.
- Content synchronisation: an SUS server can be automatically or manually synchronised with the public Windows Update service. An administrator can set a schedule for the server to automatically synchronise at preset times. Alternatively, an administrator can manually synchronise.
- Server-to-server synchronisation: because administrators may need to run SUS on multiple servers inside an organisation in order to make the updates local to computers for downloading, SUS allows synchronisation from to another server running SUS instead of Windows Update. This allows for a single point of entry for updates into the network, without requiring that each SUS server download updates from the external Microsoft source. In this way, updates can be more easily distributed across the enterprise.
- Update package hosting flexibility: administrators have the flexibility of downloading the actual updates to their intranet site or pointing computers to a worldwide network of download servers maintained by Microsoft. Downloading updates directly might appeal to an administrator with a network closed to the Internet. Large networks spread over geographically disparate sites might find it more beneficial to use the Microsoft-maintained download servers. In this scenario, an administrator would download and test updates at a central site, then point computers requiring updates to one of the Windows Update download servers while maintaining control over which updates are installed.
- Multi-language support: although the SUS administrative interface is available in only English or Japanese, the server supports the publishing of updates to multiple operating-system language versions. Administrators can configure the list of languages for which they want to download updates.
- Remote administration via HTTP or HTTPS: the SUS administrative interface is web-based and therefore allows for remote (internal) administration using Internet Explorer 5.5 or later.
- Update status logging: administrators can specify the address of a web server where the automatic updates client should send statistics about updates that have been downloaded and whether the updates have been installed. These statistics are sent using the HTTP protocol and appear in the Microsoft Internet Information Services (IIS) log file of the web server.
SUS group policy object settings
The SUS group policy object settings are defined in a single administrative template file, wuau.adm.
Future enhancements
According to Microsoft’s FYI publication, Microsoft is looking to improve the patching experience through further integration of the many channels through which updates are issued, improved Windows Installer (MSI) technology and SUS v2.0, which is currently due for a Summer 2004 release with a number of benefits including:
- SUS administrators will be able to uninstall updates.
- Forced patch application (by a certain date).
- Improved granularity in scheduling downloads.
- Better reporting tools.
- Support for Office 2003, SQL Server, Exchange Server and critical driver updates.
SUS best practice
Following on from my overview of Microsoft Software Update Services (SUS), this post suggests some best practices that should be applied to patch management using SUS.
Check daily for correct SUS synchronisation
Each day, the Microsoft Software Update Services administrative tool should be used to view the synchronization log. This will indicate if there were communications issues when the SUS server attempted to download updates. Sometimes this may be caused by a temporary network or server outage and the synchronisation process can be re-run.
Test updates before approval
Before approving updates, they should be fully tested on using reference PCs away from the production network. All updates that have been downloaded from the Microsoft Windows Update servers to SUS will be available at c:\inetpub\sus\content\. The level of testing required must be set to satisfy the organisation’s internal requirements. Generally there will not be problems with other Microsoft products (and any such problems will be well publicised); however updates should ideally be integration tested against the desktop standard operating environment (SOE) including any third-party products in use.
Even if the network is protected from an Internet-based attack, laptop users are always vulnerable, and in general, the risk associated with the application of a critical update is lower than the risk of not applying that patch.
Examine the IIS logs
IIS maintains log files of all client requests. Although complex, these can be found at %systemroot%\system32\logfiles\w3svc1\. A tool for examining IIS logs is available on the Internet and will show clients contacting the server and downloading updates.
Small logs may indicate a problem with client downloads but could also indicate that there are no updates to be downloaded at that time.
Examine the client logs
When updates have recently been approved, examining %systemroot%\windows update.log will confirm whether or not updates have been successfully downloaded to a client. Spot checks can be used to check that the SUS process is performing well.
A successful download will be recorded similarly to the following:
2004-02-13 14:05:09 14:05:09 Success IUCTL Starting
2004-02-13 14:05:09 14:05:09 Success IUCTL Downloaded iuident.cab from http://susservername.domainname.com to C:\Program Files\WindowsUpdate\V4
2004-02-13 14:05:09 14:05:09 Success IUENGINE Starting
2004-02-13 14:05:10 14:05:10 Success IUENGINE Determining machine configuration
2004-02-13 14:05:10 14:05:10 Success IUENGINE Querying software update catalog from http://susservername.domainname.com/autoupdate/getmanifest.asp
2004-02-13 14:05:10 14:05:10 Success IUENGINE Determining machine configuration
2004-02-13 14:05:10 14:05:10 Success IUENGINE Querying software update catalog from http://susservername.domainname.com/autoupdate/getmanifest.asp
2004-02-13 14:05:10 14:05:10 Success IUENGINE Determining machine configuration
2004-02-13 14:05:11 14:05:11 Success IUENGINE Querying software update catalog from http://susservername.domainname.com/autoupdate/getmanifest.asp
2004-02-13 14:05:11 14:05:11 Success IUENGINE Determining machine configuration
2004-02-13 14:05:12 14:05:12 Success IUENGINE Querying software update catalog from
2004-02-13 14:05:12 14:05:12 Success IUENGINE Determining machine configuration
2004-02-13 14:05:12 14:05:12 Error IUENGINE Querying software update catalog from http://susservername.domainname.com/autoupdatedrivers/getmanifest.asp (Error 0x80190194)
2004-02-13 14:05:12 14:05:12 Success IUENGINE Shutting down
2004-02-13 14:05:12 14:05:12 Success IUCTL Shutting down
2004-02-13 14:11:05 14:11:05 Success IUCTL Starting
2004-02-13 14:11:05 14:11:05 Success IUENGINE Starting
2004-02-13 14:11:05 14:11:05 Success IUENGINE Install started
2004-02-13 14:11:07 14:11:07 Success IUENGINE Installing SOFTWARE item from publisher com_microsoft
2004-02-13 14:11:07 14:11:07 Success IUENGINE Installer Command Type: EXE
2004-02-13 14:11:26 14:11:26 Success IUENGINE Installing SOFTWARE item from publisher com_microsoft
2004-02-13 14:11:26 14:11:26 Success IUENGINE Installer Command Type: EXE
2004-02-13 14:11:45 14:11:45 Success IUENGINE Installing SOFTWARE item from publisher com_microsoft
2004-02-13 14:11:45 14:11:45 Success IUENGINE Installer Command Type: EXE
2004-02-13 14:11:49 14:11:49 Success IUENGINE Installing SOFTWARE item from publisher com_microsoft
2004-02-13 14:11:49 14:11:49 Success IUENGINE Installer Command Type: EXE
2004-02-13 14:13:09 14:13:09 Success IUENGINE See iuhist.xml for details: Install finished
2004-02-13 14:13:09 14:13:09 Success IUENGINE Shutting down
2004-02-13 14:13:09 14:13:09 Success IUCTL Shutting down
The error message in the transcript above can be ignored as SUS cannot serve driver updates (unlike Microsoft’s public Windows Update servers, for which the automatic updates client is also used).
Check for security misconfigurations
The Microsoft Baseline Security Analyzer (MBSA) should be run periodically to check for security issues. For example, if a workstation has not been restarted after updates have been applied, then it will not download new updates from SUS. MBSA will highlight workstations which are not fully patched.
Connecting to a server’s console session using RDP
One of my colleagues introduced me to a switch I had mot previously encountered for connecting to the console session on a server using the Microsoft Terminal Services/Remote Desktop Connection (RDP) client. Although not presented by the GUI interface, the mstsc
command includes the /console
switch. For the full command syntax, type mstsc /?
or refer to the Microsoft Windows Server 2003 product documentation.