Migrating from Exchange Server 5.5 to Exchange Server 2003

Posted on By Mark Wilson

With Microsoft Exchange Server 2003, Microsoft have made Exchange installation simpler – the Exchange Server deployment tools and documentation (ExDeploy) lead an administrator through the entire Exchange Server installation or upgrade process and it is recommended that Exchange Server 2003 Setup is run using ExDeploy. Specific tools and utilities can be used to verify that the organization is ready for the Exchange Server 2003 installation.

For a variety of reasons, the majority of organisations moving to Active Directory perform a migration rather than an upgrade. The main reason for this is that the legacy Windows NT domain structure is generally over-complicated, often having grown organically with various resource domains created to support applications, and so may be poorly matched to the current organisational structure. Implementing a totally new directory is often the simplest method of re-engineering this, allowing for domain consolidation and improved flexibility post-migration.

Messaging connectivity is fairly straightforward to provide – that is at the core of the Exchange Server product – the main issues for Exchange Server are around directory management.

Because Exchange Server 4.0-5.5 use their own directory service and Exchange Server 2000 and 2003 use Active Directory, in a mixed environment it is necessary to synchronise directories using the Active Directory Connector (ADC). Note that there are two commonly available versions of this tool – the Windows 2000 version is not suitable for Exchange and the Exchange version should always be used.

The Exchange Server directory allows one user to be linked with several mailboxes (e.g. a primary mailbox and a resource mailbox) but Active Directory has a 1:1 relationship between a user account and a mailbox; however, ADC can create a disabled user account with an associated mailbox for resource accounts (permissions on the mailbox can then be delegated to one or more users).

The NTDSNoMatch utility can assist administrators by checking for mailboxes with a duplicate primary Windows NT account and determining if the mailbox is the primary mailbox or a resource mailbox. Following this, it creates a comma-separated value (.CSV) file that can be imported into the Exchange 5.5 directory to automatically set Custom Attribute 10 to NTDSNoMatch for the resource mailboxes. The ADC uses this attribute to match a mailbox that does not have NTDSNoMatch set to the correct user account.

The ADC uses a series of connection agreements (CAs), which are set as primary (i.e. synchronise and create objects as necessary) or non-primary (synchronise only). One- or two-way CAs can be configured and if required, a CA could be primary in one direction, and non-primary in the other. This primary and non-primary arrangement prevents duplicate entries in the global address list (GAL) from being created as a result of various CAs synchronising with multiple sites.

In mixed mode, recent versions of Exchange Server provide a service called the site replication service (SRS), which makes an Exchange 2000/2003 routing group appear as a site to the Exchange 5.5 infrastructure (cf. native mode, where Exchange Server 5.5 interoperability is not supported).

The SRS acts as an endpoint for a configuration CA, created in the ADC by Exchange Setup. This allows SRS to funnel organisational changes made in Active Directory into the legacy Exchange directory service, where they propagate to the legacy servers via standard directory service replication.

Recipient and public folder CAs are created by an administrator. These should be configured to point at the SRS rather than a legacy Exchange server so that legacy servers can be decommissioned without losing synchronisation with Active Directory. When all legacy servers have been decommissioned, the SRS is no longer required. Note that even when hosting the SRS, an Exchange Server 2003 server still read directly from Active Directory (using DSAccess) and the SRS is only for the benefit of Exchange Server 4.0-5.5 servers.

If an organisation creates an Active Directory to support Exchange Server 2003, and completes the Exchange migration before all the NT domains have been migrated to Active Directory, duplicate accounts will be created. The ADClean tool can be used to merge duplicate accounts and is installed with Exchange Server 2000 and 2003.

The whole migration process from Exchange Server 5.5 to 2003 is summarised as follows:

Exchange 5.5 to 2003 migration

  1. Install Active Directory on a new Windows 2000 or Windows Server 2003 server
  2. Migrate NT objects to Active Directory using the Active Directory Migration Tool (ADMT) – this will require a trust to be in place between the legacy and new domains.
  3. ADMT manages SID history to ensure that new accounts in Active Directory still have access to resources in the NT domain (including permissions over their Exchange Server 5.5 mailboxes.
  4. Run Exchange Server setup once with the /forestprep switch to prepare the Active Directory Schema for Exchange and again with the /domainprep switch for each domain in the forest which will host Exchange Servers (ADC installation in 5 would make some changes, but not all).
  5. Install the ADC on a member server within the Active Directory forest. Create recipient CAs and use the NTDSNoMatch utility to check for mailboxes with a duplicate primary Windows NT account.
  6. Install a new Exchange Server 2003 server, ideally into the Exchange Server 2003 administrative group which corresponds to the existing Exchange server 5.5 site (i.e. same organisation). Alternatively, a new organization can be created.
  7. Use the Move Mailbox Wizard to move mailboxes from legacy Exchange servers to the new server. This is multi-threaded in Exchange Server 2003 and so much faster than in Exchange Server 2000. Outlook clients will automatically be updated via the directory referral method and so a client visit is not required. If a new Exchange organization was created in 6, it will be necessary to use the ExMerge tool to migrate data and to reconfigure each Outlook client with a new profile. The public folder migration tool can be used to migrate system and public folders.
  8. Once all of the data is migrated, the legacy Exchange Server 5.5 servers may be decommissioned and Exchange Server 2003 switched from mixed to native mode (note that this is entirely separate from the mixed and native modes for Active Directory).
  9. Optionally, ADSI Edit can be used to restructure administrative groups (unsupported by Microsoft).
  10. Finally, the ADC may be decommissioned and the SRS disabled.

Building a Windows cluster using VMware

Posted on By Mark Wilson

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

Posted on By Mark Wilson

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).

Overview of the Microsoft Baseline Security Analyzer

Posted on By Mark Wilson

Like Microsoft Software Update Services, the Microsoft Baseline Security Analyzer (MBSA) is a security toolkit component born out of the Microsoft Strategic Technology Protection Program (STPP).

MBSA v1.2 is available for download from the Microsoft website and provides a graphical and command line interface that can perform local or remote scans of Windows systems. MBSA runs on Windows Server 2003, Windows 2000, and Windows XP systems and will scan for common security misconfigurations in the following Microsoft products:

  • Windows NT 4.0.
  • Windows 2000.
  • Windows XP.
  • Windows Server 2003.
  • Internet Information Services (IIS) 4.0, 5.0, and 6.0.
  • SQL Server 7.0 and 2000.
  • Internet Explorer (IE) 5.01 and later.
  • Office 2000, 2002 and 2003.

MBSA also scans for missing security updates for the following Microsoft products:

  • Windows NT 4.0.
  • Windows 2000.
  • Windows XP.
  • Windows Server 2003.
  • IIS.
  • SQL.
  • Exchange.
  • IE.
  • Windows Media Player.
  • MDAC.
  • MSXML.
  • VM.
  • Office.
  • Content Management Server.
  • Commerce Server.
  • Host Integration Server.
  • BizTalk Server.

MBSA replaces and expands on the former HFNetChk tool to check for required hotfixes but two useful command line variants (which must be run from the folder where Microsoft Baseline Security Analyzer is installed) are:

mbsacli /hf -h computername -u username -p password

(used to check against the Microsoft Windows Update servers for missing hotfixes); and:

mbsacli /hf -h computername -sus susservername -u username -p password

(used to check against a specified SUS servers for missing hotfixes).

MBSA should be run periodically to check for security issues, finding workstations with vulnerabilities and/or weak passwords, allowing steps to be taken to force a user to take action.

SUS best practice

Posted on By Mark Wilson

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.

Overview of Microsoft Software Update Services

Posted on By Mark Wilson

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.

Tracking down IBM BIOS updates

Posted on By Mark Wilson

The IBM website is not always the easiest to navigate and I spent ages today tracking down the latest BIOS for a number of servers. To save someone else the same issues in future, I recommend that to quickly find the latest BIOS for a PC or server, search for +flash +BIOS +update +modelnumber.

More search tips are available from the IBM website.

Connecting to a server’s console session using RDP

Posted on By Mark Wilson

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.

Controlling the creation of Active Directory replication connections

Posted on By Mark Wilson

The knowledge consistency checker (KCC) is a Microsoft Windows 2000 and Microsoft Windows Server 2003 component that automatically generates and maintains the intra- and inter-site replication topology.

Whilst the KCC generally works well, sometimes it may be necessary to prevent the KCC’s automatic generation of replication connections (a scripted method is also available).

It should be noted that manually creating Active Directory connections to tailor the replication topology increases the administrative workload as the KCC will no longer dynamically alter connections to reflect changes in the network topology or replication failures.

Further information on optimising Active Directory replication is available on the Microsoft website.