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.

Understanding and developing with SharePoint products and technologies

I recently attended an event at Microsoft about understanding and developing with Microsoft SharePoint services. I should point out that I’m not a developer, so some of the development topics meant very little to me, but I have reproduced the bits I understand here anyway!

The need for collaborative applications

According to a 2002 report by Gartner: employees get 50%-75% of their relevant information directly from other people; more than 80% of enterprise’s digitised information reside in individual hard drives and in personal files; and individuals hold the key to the knowledge economy with most of that knowledge being lost when they leave the enterprise. Not surprisingly, Microsoft has interpreted this as a need to provide easy to use and effective collaboration tools and technologies, citing that CEOs recognise that improving knowledge worker productivity will play a major role in their business’ ability to compete.

SharePoint products and technologies

Microsoft claims that its SharePoint products and technologies strategy facilitates a consistent rich experience for users, developers, and IT staff; smart connections for people, teams, divisions or the enterprise; and will support flexible deployment – bottoms-up, centralised, or hybrid on large scale farms.

Despite Microsoft’s claims, this SharePoint products and technologies naming can be confusing as Microsoft actually has two separate products which use the SharePoint name. The basic Windows SharePoint Services (WSS) product is shipped with Windows Server 2003 whereas SharePoint Portal Server (SPS) is a chargeable product which provides extra functionality, bringing SharePoint sites together as a single portal, to make them navigable, searchable, and adding enterprise level features such as:

  • Hierarchical navigation and category services with areas and topics.
  • Publishing and alerts.
  • Search/cross-enterprise indexing (using an okapi probabilistic ranking algorithm).
  • Line of business integration and single sign on (SSO) and BizTalk integration.
  • Document management (alerts, version control and check-in/out).
  • Profiling system.
  • Personalisation (My Sites).

WSS is actually v2.0 of the earlier SharePoint Team Services (STS) product but whereas STS v1.0 only shared the SharePoint name, WSS and SPS are now very tightly integrated. Nearly all SharePoint content is stored in a SQL Server (or MSDE) database.

Microsoft is positioning SharePoint as a platform for an integrated work environment with:

  • Application integration – providing a single place where knowledge workers go to to their work (in context), improving efficiency. Because Office 2003 applications integrate with WSS, Word’s Research Pane can be used to search across the Internet, or a SharePoint-based intranet; by adding document properties to a view (using the same names as in Word), Word document properties can be displayed on a SharePoint site; another example of Office product integration is using InfoPath 2003 for electronic forms, stored and accessed via a WSS forms library, allowing the data to be queried, merged, etc.; Outlook 2003 is SharePoint aware and gives users the option of creating a document workspace, rather than sending an attachment many times over. Users don’t have to be on the latest versions of Office to benefit from SharePoint integration but each new version provides tighter integration and greater functionality: Office 2000 users can save and retrieve documents to a SharePoint repository; Office XP allows users to manage SharePoint lists; but it is Office 2003 that provides the greatest level of integration including colleague presence, instant messaging and site creation directly from Office System applications.
  • Collaboration – out of the box, WSS can be used to manage document lifecycles using document workspaces; facilitate organisation of meetings with meeting workspaces and their integration with Outlook 2003; facilitate communication and build consensus with forums for discussion of team activities and surveys to gather information on team status. Through integration with Live Communications Server (LCS), SharePoint is able to show team members of sites or workspaces as being online or offline to allow instant messaging if desired. Finally, with SPS, notifications and alerts can be sent when chosen documents (or entire lists) change or are added, improving workflow.
  • Personalisation – provided through SPS’s MySite functionality, a personal site where users can save their own private data and make some of that data public but one which also allows for built-in functions to allow viewing of content directed at audience groups that the user is a member of.
  • Scalability – because SharePoint is based on the .NET Framework and SQL Server 2000 it will scale up for improved performance. It will also scale out to a three tier application architecture with separable components for web rendering, database, searching and indexing, allowing web servers to be added as the load increases and SQL storage to be added as the data increases. SharePoint also supports the use of storage technologies such as SANs for disaster recovery and multiple server farms working together.
  • Customisation/extensibility functionality – SharePoint sites, lists and views can be customised in Internet Explorer or with FrontPage. Whilst FrontPage is not required to customise WSS, it does allow a lot more flexibility (especially when working with web parts). No coding is required for immediate use of SharePoint, but it is extensible using its ASP.NET object model which allows the creation of web parts and direct mode .ASPX pages.
  • Manageability – SharePoint provides improved administration with flexible roles to control site usage, specifying quotas and removing dead sites, as well as more granular management for backup and restoration.

SharePoint architecture

Windows SharePoint Services (WSS) Architecture

SharePoint works by installing an ISAPI filter in IIS, which separates content into static content – including folder views, via distributed authoring and versioning (DAV) – and dynamic content.

The dynamic content is further separated into application pages (direct mode) and user pages (safe mode), which are generally more fluid.

A web part is an ASP.NET server control which is deployed as an assembly. Web parts cannot be run unless they are safe (in order to prevent users from adding their own web parts that may have undesirable effects).

Direct mode pages reside in the file system of the web server and are processed with the standard ASP.NET runtime processing model. Direct mode pages are available for all sites on a server computer and are placed in the _layouts directory whilst _vti_bin contains a set of web services which may be called remotely.

Safe mode pages exist within the content database and can be customised and personalised; however they can only use web parts marked as safe and can not directly use in-line scripts.

When a site is created, user is specified as the site administrator. A template is then applied to the site and either shared or individual versions of pages may be modified. Each page is divided into zones, which are used to control the areas of the page which can be customised (e.g. the left zone may be fixed).

The okapi ranking used by SPS for search results is interesting – rather than using Windows’ Indexing Service, SharePoint has it’s own crawler/indexer and then uses the okapi algorithm to rank the results, so the whole process is similar to:

  1. First expand the query to think about which columns make the most sense – weigh particular terms and fields as more important at query time (avoiding re-indexing to change weightings). Also coerce a field called the best bets field and make it really important in the overall ranking.
  2. Break the query terms down and get alternate term forms (stemming – ran, running etc.) doing this in the query maintains the fidelity of terms in the index, and expand the thesaurus for related terms.
  3. Now do the recall phase – find all the documents that match one of the terms in the query – this will result in a large list which is then trimmed down to the documents that a user has access to, and only the documents within the scope of the query.
  4. Finally, allow the probability algorithm to do the precision phase – ranking the best fit documents at the top of the list.

Web parts are installed using the SharePoint Administration Tool (stsadm.exe). This tool also allows items to be saved as a template and brought in to another site, e.g. between development, test and production sites. Additionally, a whole site can be saved into a template library.

Using the stsadm.exe tool to deploy web parts requires a .CAB file (built with Visual Studio) containing:

  • WebPart assembly.
  • Description of contents (manifest.xml).
  • Description of web part (as a .DWP file).

Example stsadm.exe command lines are:

  • stsadm –o addwpppack –filename mycab.cab
  • stsadm –o deletewppack –name mycab.cab
  • stsadm –o enumwppacks

For security, SharePoint can use either Active Directory (AD) or the local security database. Because of this, anonymous access is supported, as is use of built-in AD groups.

Administrators and developers should be made aware that when WSS is installed (onto a server with IIS), it installs into the default web site and makes drastic changes to the web.config file , for example, directing *.ASPX to SharePoint and setting the trust level to WSS_Minimal. Because of this, any existing applications running on the default web site will probably not work and although the changes can be undone, it is probably easiest to install WSS onto its own server (or to move other web applications to their own web site prior to installation).

Developing with SharePoint

SharePoint uses its own object model to create the user interface, so there are no hidden
APIs; however to develop on a Windows XP machine (where WSS will not be available), a few additional DLLs from WSS will be required:

  • Microsoft.SharePoint.DLL
  • Microsoft.SharePoint.Portal.DLL
  • Microsoft.SharePoint.Portal.SingleSignOn.DLL
  • Microsoft.SharePoint.Security.DLL

There is also a SharePoint products and technologies software development kit (SDK), which contains a single file (spptsdk.chm).

SharePoint supports a number of application types:

  • Web parts.
  • .ASPX pages.
  • Console/Windows tools.
  • Document library events.
  • Remote client via web services.

Web parts can be used in either static or dynamic scenarios and are rendered through RenderWebPart(HtmlTextWriter). Each web part cab have custom properties, the values for which can be stored per-zone (Storage.Shared) or per-user, per-zone (Storage.Personal) and the attributes for which are used to control storage, default values and the property user interface. Web parts can make use of child controls in order to achieve their requirements and support connection interfaces to allow the parts to communicate with each other at run time (e.g. as consumer and provider for a cell, list or row). Connections can be either client side or server side but cannot be mixed.

When deploying web parts, ASP.NET needs to be able to find the web part assembly, which can either be placed it in the global assembly cache (GAC) or placed in a private bin folder for the web site. Additionally, types have to be marked as safe in web.config. In order to load the web part into SharePoint, it must be packaged as a .DWP file.

Code cannot exist inline on a page within the site and creating pages in the _layouts directory is often the best option for custom .ASPX applications on top of SharePoint as it allows the page to be accessible from any site. For example, if mypage.aspx exists in in _layouts, it is accessible from the following URLs:

  • http://myweb/_layouts/myapp/mypage.aspx
  • http://myweb/subweb/_layouts/myapp/mypage.aspx

.ASPX pages run using the context of the web under which they is running.

A console tool is the best option for writing code that performs operations on multiple sites (e.g. list the URL and size of each site on the farm; or process all document libraries and archive file versions more than six months old).

SharePoint supports events on document libraries with operations such as add, update, delete, check-in, check-out, etc. Events are asynchronous and call the IListEventSink managed interface, running in the context of the IIS worker process.

SharePoint also has a web services APIs for accessing content remotely (e.g. from a Microsoft Office 2003 application). The web services layer is built on top of the server object model and allows manipulation of lists, webs, views, list items, etc. Functionality is similar to the server object model, but with fewer interfaces optimised to minimise transactions. Web services are added as web references in Visual Studio.NET and available web service include:

  • lists.asmx (list information).
  • webs.asmx (web information).
  • views.asmx (view information).
  • alerts.asmx (alerts).
  • admin.asmx (administering sites).
  • permissions.asmx, usergroups.asmx (site permissions).
  • versions.asmx (file version information).
  • infoforms.asmx (form information).

It will often be necessary to send the logged on users’ credentials from the client in order to make use of web services. This may be achieved by adding the following code in the web reference object’s constructor:

public Lists() {
this.Url = http://server/_vti_bin/lists.asmx;
this.Credentials=System.Net.CredentialCache.DefaultCredentials;
}

Besides using SharePoint’s own web services, it is possible to build custom web services and place them in the _vti_bin directory.

The SharePoint Object Model
The SharePoint object model has four top-level objects:

  • SPWeb (represents an individual site).
  • SPSite (represents a site collection, which is a set of web sites).
  • SPVirtualServer (represents a virtual server).
  • SPGlobalAdmin (used for global administration settings).

In order to perform actions on data within a web, it is necessary to first get an SPWeb object (e.g. SPWeb MyWeb = SPControl.GetContextWeb(Context);)

The complete object model is grouped into lists, files (documents), security and administration:

  • Lists – use these objects under the Microsoft.SharePoint namespace to view and edit data in SharePoint lists:
    • SPList (basic list object for getting to list data).
    • SPListCollection (collection of list objects).
    • SPListItem (item/row in a list).
    • SPListItemCollection (collection of list items).
    • SPView (view of a SharePoint list).
    • SPField (field/column in a list).
    • SPListTemplate (template for a list).
  • Files – use these objects under the Microsoft.SharePoint namespace to access document files in SharePoint sites:
    • SPFile (file object).
    • SPFileCollection (collection of files).
    • SPFileVersion (version of a file).
    • SPFolder (folder object).
    • SPDocumentLibrary (document library object).
    • SPDocDiscussion (discussions on a file).
    • SPDocTemplate (used when creating a new file).
  • Security – use these objects under the Microsoft.SharePoint namespace to edit access rights and security information:
    • SPUser (user object).
    • SPRole (site group object).
    • SPGroup (cross-site group object).
    • SPPermission (assigned permissions).
    • SPRightsEnumeration (available permissions).
  • Administration – use these objects under the Microsoft.SharePoint.Administration namespace to edit server-wide administrative settings.
    • SPGlobalAdmin (top level administration object).
    • SPVirtualServer (virtual Server object).
    • SPQuota (storage/user quota limit object).
    • SPGlobalConfig (configuration options).
    • SPSiteCollection (collection of sites on a virtual server).

In terms of mapping the user interface onto the object model terminology:

  • Site Collection = site.
  • Site = web.
  • Top-level site = rootweb.
  • Subsite = subweb.

Tips and Tricks

Paul Appleby, from Microsoft UK’s Developer and Platform Group, gave the following advice for developing applications with SharePoint:

  • Keep objects around. If objects are created and destroyed objects frequently, extra SQL queries will be required.
  • In spite of the point above, free objects when they are no longer required, calling close or dispose on web and site objects.
  • Use SPWeb Web = SPControl.GetContextWeb(Context); to get the current SPWeb object from a web part or .ASPX page.
  • SPGlobalAdmin and SPSite are the only SharePoint objects created with new. All others are opened from another object.
  • The URL taken by the SPSite constructor must be absolute, and must refer to the actual computer name, not the load-balanced name.
  • Send the user’s credentials to the server when using web services to access data in SharePoint sites and include <sharepoint runat="server" /></sharepoint> in any .ASPX page that needs to make updates.
  • To optimise performance, use foreach() to step through collections. Iterating through collections by index can result in unnecessary database calls to collections such as lists. Items are expensive. Preserve the collection rather than requesting it again.
  • For best performance, use SQL Profiler to minimise the number of queries that an application makes to the database.

Links

Microsoft SharePoint products and technologies.
Microsoft SharePoint products and technologies software development kit (SDK).

BizTalk Server 2004 Overview

Microsoft BizTalk Server has been around for a few years now and apart from some hands on labs at a Microsoft Tech Ed conference, I’ve not had much opportunity to get involved with it. As BizTalk Server 2004 is the product’s third incarnation and it seems to be gaining momentum in the marketplace, I attended a presentation given by Nick Page (a Technical Evangelist at Microsoft UK) and the following are my notes from the event.

Today’s IT environments are complex with multiple servers, operating systems and protocols, many disparate applications (ERP, HR, Finance) and many programming models (e.g. COM, J2EE, .NET, CICS). At the same time, organisations are demanding integration between internal systems, and integration with business partners.

Tightly-coupled systems impose many dependencies, requiring lots of commonality between systems (e.g. those of an organisation and its business partners), whereas loosely-coupled systems lend themselves to a service orientated architecture (SOA). In this context, a service is a reusable business process or business function, that can be accessed through public and private networks.

In the past, attempts to standardise integration technologies have been hampered by a lack of industry acceptance and adoption but today we have a ubiquitous network (the Internet), a ubiquitous data format (XML) and all major vendors support XML web services.

The web services dream is for each line of business (LOB) system to be connected to all the applications from which it needs to consume services.

Web services

This is all very well, but once more than one system is involved the mesh of connections becomes difficult to manage.

Web services chaos
The answer lies in the use of an integration server, and Microsoft’s enterprise application integration (EAI) product is BizTalk Server, although BizTalk offers more than just EAI.

Web services integration

BizTalk Server 2000 and 2002 separated messaging and orchestration. BizTalk Server 2004 re-integrates the two, using an architecture which is summarised in the following diagram.

Microsoft BizTalk Server

BizTalk Server includes an adapter framework to build adapters (which are actually Microsoft .NET components) and all BizTalk Server 2004 adapters are configured in the same manner (unlike previous versions). Examples of adapters may be:

  • A file system adapter, which looks for the presence of a new file in a particular location.A SQL adapter, which understands the database schema.
  • An HTTP adapter, for transport.
  • An API adapter (e.g. SAP), mapping XML messages to native application programming interfaces (APIs).

Out of the box, BizTalk Server includes EDI, flat file, FTP, HTTP, SOAP and SQL adapters but many more are available from ISVs.

As messages (with context) pass through the pipeline, components are used to translate/process the message resulting in and XML output. Sometimes, this processing takes place within the adapter – the decision where to put the processing depends on whether they will be reused or not (e.g. if there are many adapters working with the same transport, such as flat file .CSV, then this processing may be put in the pipeline). An example use for a component would be to validate messages against a schema. Standard components included with BizTalk include XML receive and pass-through receive.

With BizTalk Server 2004, all components act directly on the messages, whereas previous BizTalk Server versions used the Microsoft Message Queue (MSMQ).

By promoting part of a message into context (i.e. putting it into the property schema), then messages can be routed on content, avoiding the requirement to load the whole message at each stage in the pipeline.

The business rules portion of the process is where the orchestration takes place, defining processes that interact with systems and apply business logic to the XML messages.

The message box is a SQL Server database, used to store the XML messages, which have rich properties, allowing them to be linked to services through a publish/subscribe model. Unlike in previous versions of BizTalk Server, from 2004, all messages pass via the SQL Server and a single message passed into the message box database work queue could result in multiple outgoing messages (each one a copy of the original), based on the subscriptions of other services.
The configuration database contains details of all the ports in the integration, whilst the tracking database tracks the progress of the message.

BizTalk Server 2004 ports are intended to be stateless so as to allow for scaling in/out (e.g. using network load balancing), with SQL Server stored procedures carrying out the routing so that many processing servers may be provided for one common database; however there are some exceptions – persisted (long running) transactions, correlation messages and session-based protocols all need to be routed to the correct server. Storage can also be scaled out using multiple SQL Servers but if clustering is used, then there will be a 30-60 second delay during a cluster failover.

Just as pipeline components are used to parse and serialise messages, message security is provided using components in the pipeline, for example decrypting/encrypting/signing messages or resolving parties (i.e. mapping to a certificate). It is also possible to segment security with multiple logical hosts using different service accounts. This is particularly useful if multiple suppliers are involved in a process, where BizTalk will reject incoming messages with no party ID and the message box will not allow messages from untrusted hosts. The incoming and outgoing ports may use separate service accounts, as may the orchestration element.

BizTalk Server is designed for throughput (scalability) and not latency (sub-second point-to-point responses), so orchestration processes are not left running and waiting for a response indefinitely as this will consume system resources unnecessarily. Instead, processes are dehydrated to the database and correlation (a collection of message properties) is used to about matching incoming messages to orchestration processes and rehydrate processes as necessary.

For developing solutions, BizTalk Server 2004 includes the BizTalk project system (hosted within Microsoft Visual Studio), to provide an environment for designing, organising, and building the various elements of BizTalk applications.

When a BizTalk project is created, it generally includes one or more of the following file types which play specific roles in the creation of the business solution, and the BizTalk project system provides a corresponding graphical design tool for each of them.

  • Orchestrations model the business process. Orchestration Designer simplifies the process of creating orchestrations (models of business processes that are compiled into executable code).
  • Schemas describe the data that is sent and received. BizTalk Editor simplifies the process of defining schemas. Schemas are used to describe the format of data that is processed within organisations and between trading partners.
  • Maps transform data from one format to another. BizTalk Mapper presents source schemas and destination schemas side-by-side and enables the definition of transformations between data elements of different messages.
  • Pipelines perform a variety of operations to prepare incoming or outgoing messages for further processing. Pipeline Designer allows the preparation of incoming and outgoing messages for further processing by implementing such operations as encryption and decryption, compression, reformatting, and validation.

Other BizTalk terms include:

  • Functoids – used to map two schemas and transform data (e.g. cumulative sum, database lookup, or run a script, calling out to external or in-line code). The transformation can occur wherever the messages are in XML format (i.e. after the pipeline or during orchestration).
  • Vocabulary – mapping English terms/descriptions to elements within a message.Policy – a set of rules used to work on vocabulary or message elements. These rules are deployed to BizTalk servers but by extracting the rules from the business process, the rules are not hard coded and so allow for modification in line with business process changes.
  • Envelopes – used to wrap the core data when receiving (disassembling) or sending (assembling) messages.
  • Long-running transactions – when business processes last longer than a few seconds (e.g. send a request for assessment and expect a response after a few days). The converse is a short-running transaction, which uses a locking mechanism but this is too resource-intensive to scale so BizTalk Server 2004 has the concept of flexible delay.
  • Compensation – if a process aborts and affects the results of a previously completed transaction, it cannot be undone. Compensation processes are used for actions which cannot be undone.
  • Exception block – the method by which BizTalk Server 2004 deals with exceptions when external calls go wrong.

Finally, some of the other features provided by BizTalk Server 2004 include:

  • Single sign on (SSO) capabilities – mapping user credentials from Windows to non-windows systems allowing services to authenticate once and then securely access target systems. An encrypted secret store contains the user mappings. BizTalk Server’s SSO integrates with Windows SharePoint Services (WSS) to provide SSO for a portal and has a web services front end for any client to any platform.
  • Business activity monitoring (BAM) – allowing users to query an OLAP cube from within Microsoft Excel and ask near real-time questions such as “how long is production taking right now?” or aggregation questions such as “how much money did we make last month?”. Because the OLAP cube is extracted from the database, it is not quite real time. This can use data from documents or process and complements the existing SQL Server business intelligence (BI) offerings.
  • Health and activity monitoring – this includes the Orchestration Debugger, which allows a message to be replayed through a process to follow calls into other Orchestrations, view exceptions thrown and examine any compensation code executed; or alternatively to attach to live orchestrations, setting breakpoints, watching variables and retrieving message contents before resuming processing until the next breakpoint.
  • Human workflow services (HWS) – business analysts and developers can use standard orchestration processes for interaction, or HWS for more dynamic requirements. Each orchestration becomes a step in the workflow with permissions; however HWS is all about background processing and has no user interface, so third party products are needed to expand on this.

10,000 feet view of Microsoft ISA Server 2000

Microsoft Internet Security and Acceleration (ISA) Server 2000 is Microsoft’s firewall and proxy server product, replacing Microsoft Proxy Server.

ISA Server 2000 operates in one of three modes:

  • Firewall – security server.
  • Caching (i.e. proxy) – acceleration server.
  • Integrated – firewall and caching.

As a firewall, ISA Server’s filtering capabilities include:

  • Packet filtering (layer 3) capabilities – filtering based on the source and destination IP addresses along with their respective port numbers.
  • Circuit (TCP) and stateful inspection (UDP) filtering – filtering bases on a sequence of packets (e.g. to guard against denial of service attacks).
  • Application filtering (layer 7) – actually inspecting the data segment of the packet.

(layer numbers refer to the open system interconnection 7 layer network model).

The product can be used as an internal or external firewall and ISA Server 2000 achieved certification for Common Criteria Evaluation Assurance Level 2 (EAL 2) in September 2003.

ISA Server’s basic caching (proxy) process is as follows:

ISA Server 2000 - caching

  1. Client requests access to an external website. Because the DNS suffix address is not local, it knows to contact the proxy server.
  2. ISA Server receives the request and checks its cache, which by default is split between 50% of the ISA server’s available memory (fast) and disk (slower).
  3. If there is no match in the cache, then space is reserved in cache and the request is forwarded to the Internet, using network address translation (NAT).
  4. The external web server replies with the requested page.
  5. The reply is cached with a time to live (TTL) (default 24 hours) and is forwarded to the requesting client.

Other caching features include:

  • Active caching – as the TTL for a cached resource expires, ISA server proactively fetches the latest copy of the resource from the Internet, storing it in the cache and accelerating future requests by keeping the latest versions of the most popular sites in the cache.
  • Scheduled download – caching defined URLs on a schedule, e.g. caching a partner’s website each day for local access. This is most useful in a business to business (B2B) extranet scenario, where the content expiry can be predicted.

ISA server also supports VPN access (available in Windows 2000, XP and Windows Server 2003, but enhanced with ISA Server) and reverse publishing (allowing access to internal resources from the Internet). Reverse publishing using ISA Server is more secure than simply hosting a web server in a demilitarised zone (DMZ) as there is a firewall with NAT between the Internet and the DMZ, as well as between the DMZ and any internal resources.

Standard 3-pronged firewall with web server in DMZ:

3 pronged firewall

Reverse publishing using ISA Server:

ISA Server 2000 - reverse publishing

The configuration of ISA Server 2000 is controlled using policy elements, which are bundled together to create rules.

ISA Server 2000 Enterprise Edition allows the formulation of arrays of ISA servers, providing greater scalability.

Links

Microsoft ISA Server
Microsoft ISA Server firewall and cache resource site

Migrating from Exchange Server 5.5 to Exchange Server 2003

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

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

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.