March 2009
Office Communications Server: What’s New in Office Communications Server 2007 R2
Office Communications Server 2007 R2 introduces not only a number of brand-new features, it also delivers some significant enhancements to existing functionality. Here’s an overview of some of the most important new features and functions you’ll find in this latest release. Stephanie Pierce
Office Communications Server: How Remote Call Control Powers OCS 2007 R2
The Remote Call Control capabilities in OCS can be used to extend your R2 deployment to legacy devices. Find out how to configure Remote Call Control to provide rich OCS capabilities in an environment with a PBX system. Rajesh Ramanathan
Office Communications Server: Securing OCS with ISA Server
To securely extend your OCS 2007 infrastructure to remote users and organizations, you need to deploy one or more Edge Servers and provide reverse proxy access to these servers. Here’s what you need to know to use and configure ISA Server 2006 as a reverse proxy for your OCS deployment. Alan Maddison
Office Communications Server: Managing OCS 2007 R2 from the Command Line
Though you can configure Office Communications Server using wizards, there are times it makes sense to work from the command line. Explore the LCSCmd command-line tool and see how you can use it to set up OCS 2007 R2. Greg Stemp and Jean Ross
Office Communications Server: A Powerful Tool for OCS Planning and Deployment
The Planning Tool for OCS 2007 R2 is a wizard that provides prescriptive guidance to help you prepare to deploy R2 in your organization. Discover how you can quickly generate a topology and create a list of recommended hardware to help guide your planning and deployment efforts. Stephanie Pierce
Columns
From the Editor: The Speed of Innovation: | Letters: Readers Speak Out: | Toolbox: New Products for IT Pros: Greg Steen discusses tweaking your system with TuneUp Utilities, auditing system configurations with SysCompare Pro, and fixing configuration errors with HijackThis. He also looks at the Microsoft Press book "Configuration Manager 2007 Administrator’s Companion".Greg Steen
Exchange Q & A: Site Resiliency with SCR, Recommended Root Volume Size, and More: Should you deploy CCR-based mailbox servers in a multi-subnet environment? Can you determine the maximum latency for Outlook clients running in cached mode? Get answers to these Exchange Server questions and more.Henrik Walther | Utility Spotlight: VMC to Hyper-V Import Tool: Discover how you can use the free VMC to Hyper-V Import tool to import and then modify VMC files, easing the process of migrating older virtual machines to Hyper-V.Matthijs Ten Seldam | Utility Spotlight: Screenrecorder: Screenrecorder is a very easy-to-use screen-to-video capture program that lets users easily capture onscreen events to a small video file that can be shared with others, making it easy to record instructions or reproduce problems for more effective troubleshooting.Burak Uysaler
Utility Spotlight: Screenrecorder: Screenrecorder is a very easy-to-use screen-to-video capture program that lets users easily capture onscreen events to a small video file that can be shared with others, making it easy to record instructions or reproduce problems for more effective troubleshooting.Burak Uysaler | Inside SharePoint: Updating Security Account Credentials: The second of a two-part series, this installment discusses how automating password changes for SharePoint security accounts is complicated despite the fact that the SharePoint object model includes the necessary logic to carry out credential updates.Pav Cherny | Windows PowerShell: Automating User Provisioning, Part 1: Don Jones kicks off a four part series that will look at how you can use Windows PowerShell to create a real-world user provisioning script.Don Jones
Geek of All Trades: Tools of the Trade: Get an overview of some handy free tools created by Microsoft that cover many of the tasks IT professionals must deal with on a regular basis. These utilities will help ease the administration of file servers, Exchange servers, desktops, and more.Greg Shields | Desktop Files: Mitigating Circumstances: It’s not enough to simply wait for security problems to surface and then try to eliminate them. Wes Miller explains how real security involves proactively seeking out the root causes of vulnerabilities and fixing them.Wes Miller | Hey, Scripting Guy!: Watch the Stopwatch: The Scripting Guys demonstrate a script that times an activity and writes the results to the registry. After subsequent runs, the script retrieves the previous value from the registry and tells you both the current time and the previous time.The Microsoft Scripting Guys
Field Notes: Listening to the User: Find out how establishing a system for listening to both internal and external customers can help your IT department become a more vital part of the larger business structure.Vivek Bhaskaran | Blog Tales: WSUS clients install updates properly but don’t send any status reports back to the server: You may notice that your clients will check into WSUS and install updates properly but don't send any status reports back to the server. Here's a cool tip and a cool tool that can help.J.C. Hornbeck | Windows Confidential: The Forgotten Hotkey: Raymond Chen looks at the evolution of the Alt+Tab hotkey and how the Alt+Esc hotkey has remained unscathed.Raymond Chen


Office Communications Server
What’s New in Office Communications Server 2007 R2
Stephanie Pierce
This article is adapted from the upcoming book Microsoft Office Communications Server 2007 R2 Resource Kit (Microsoft Press, 2009).

At a Glance:
  • Call Delegation, Team Call, Group Chat
  • Desktop Sharing, Extending Voice and Conferencing
  • Enhanced Media, Simplified Management

Contents
Call Delegation
Team Call
Group Chat
Desktop Sharing
Server Applications to Extend Voice and Conferencing
Response Group Service
Outside Voice Control
SIP Trunking
Enhanced Media
Simplified Firewall Configuration for the A/V Edge Server
Archiving, CDR, and QoE Enhancements
Simplified Management
Microsoft Office Communications Server 2007 R2, or OCS 2007 R2, introduces many new features, along with significant enhancements of existing functionality. Key new features and enhancements include Call Delegation, Team Ring, Group Chat, Desktop sharing, Server applications, SIP trunking support, Enhanced media, Simplified firewall configuration for the Audio/Visual (A/V) Edge Server, Presence Enhancements, Improvements in Archiving, Quality of Experience (QoE) Enhancements, and Simplified management. In this article, I will give an overview of some of the most important new features and functionalities added in R2.

Call Delegation
The new Call Delegation feature in OCS 2007 R2 enables managers to delegate phone call handling to one or more administrative assistants or other delegates. When a delegate answers a call, the manager is notified that the call has been answered, along with the name of the delegate who answered.
Working in Microsoft Office Communicator 2007 R2, a manager selects Call Forwarding Settings and then selects a delegate from among the names in the manager's contact list. The selected delegate uses the new Office Communications Server 2007 R2 Attendant to handle calls for the manager.
The assistant can perform the following tasks (note that these capabilities apply only to phone calls; the assistant can't screen instant messaging (IM) conversations, IM conferences, or data-only calls):
  • Screen person-to-person or conference calls on behalf of the manager. These calls can be audio only, audio and video, or audio with IM
  • Join the voice portion of a conference on behalf of the manager
  • Listen to the manager's voicemail (if the manager has shared her Microsoft Office Outlook Inbox)
  • Place a person-to-person call on behalf of the manager
  • Initiate a conference call on the manager's behalf
  • Transfer calls to the manager
  • Use a shortcut to transfer a call placed on behalf of another manager, such that the two managers speak directly to each other without having to first go through an assistant
  • Proxy remote user connections to the correct Standard Edition Server or Enterprise pool. This is necessary because remote user connections cannot be redirected
Principal Components of Desktop Sharing Framework
The framework for sharing desktops includes five principal components:
Communicator Web Access Client The 2007 R2 version of the Communicator Web Access client contains the hosting and viewing components for desktop sharing. The hosting component drives the desktop sharing session. This component sends graphical data to the Application Sharing Server or another client, such as Office Communicator 2007 R2, which is capable of understanding Remote Desktop Protocol (RDP).
The viewing component displays the graphical data from the desktop sharing session to the user. Graphical data is obtained from the Communicator Web Access server. The viewer can also send keyboard and mouse data to the host by way of the Communicator Web Access server and the Application Sharing Conferencing Server.
Desktop-Sharing Client The desktop sharing client is a Web-based viewer that is hosted on the Communicator Web Access client. When sharing is initiated, meeting participants are invited to view the sharer's desktop. If they accept, the desktop sharing client launches in a new viewing pane integrated with the Communicator Web Access client.
Participants using Office Communicator 2007 R2 can launch the desktop sharing client directly from Office Communicator. Each participant's desktop sharing client receives graphical data from the Communicator Web Access server, which in turn receives it from the Application Sharing Conferencing Server.
Microsoft Office Communicator Web Access Plug-In Because the desktop sharing client is browser based, interaction with the underlying operating system has to be implemented through a native plug-in. The Microsoft Office Communicator Web Access plug-in is available as an option during installation of the Communicator Web Access client.
Communicator Web Access Server The Communicator Web Access server is responsible for setting up, tearing down, and controlling the desktop sharing session for the Communicator Web Access client. The Communicator Web Access server also sends and receives sharing data both to and from the client. The Communicator Web Access server handles media only for Communicator Web Access viewers.
Application Sharing Conferencing Server The Application Sharing Server is responsible for managing and streaming data for conferences that require desktop sharing. In multi-party conferences, the Communicator Web Access client, in the role of the desktop sharing host, dials the conferencing server directly (or, in the case of external users, by way of an A/V Edge Server). The Communicator Web Access server then connects to the conferencing server to receive desktop sharing data on behalf of the Web clients that are hosted on the Communicator Web Access server.
In Office Communications Server 2007 R2, desktop sharing components use RDP, which is also used by Terminal Services functionality in Windows Server 2003. Desktop sharing sessions that use RDP cannot support participants who are running earlier versions of Office Communications Server clients, nor can they include users of the Office Live Meeting service.
However, participants who are not running any Office Communications Server clients and do not have an Office Communications Server account can still be invited to a desktop sharing session. They join that session by simply navigating to a meeting URL hosted on the Communicator Web Access server, using a supported Internet browser.
The manager can also transfer a call to configured delegates, which are automatically placed on the Communicator 2007 R2 transfer menu. The following call delegation options are supported:
  • One manager and one delegate
  • One manager and multiple delegates
  • Multiple managers and one delegate
  • Multiple managers and multiple delegates
Team Call
The new Team Call feature in OCS 2007 R2 makes it possible to forward incoming calls to a defined team. As a result, when a team receives a forwarded call, each member's phone rings, and all members can see who forwarded the call. When a team member answers the call, the phones of all other members stop ringing.
The Team Call feature is essentially a call-forwarding option that the team leader configures in Office Communicator 2007 R2 R2 and Office Communications Server 2007 R2 Attendant. In the Call Forwarding Settings dialog box, the leader can set up a team, add members, and configure how calls are forwarded to other team members. Call team forwarding options include the following:
Ring Leader, Then Ring Team A call forwarded to a team leader first rings the leader's phone for a specified number of seconds, and then it rings the phones of all team members. Each member can see who forwarded and accepted the call. After the call is answered, all team phones stop ringing.
Ring Leader and Team Simultaneously A call forwarded to a team leader simultaneously rings the phones of all team members. After the call is answered, all team phones stop ringing.
Ring Team only during Working Hours A call forwarded to the team leader after working hours does not go to the team.
Ring Team when Leader Status Is Set to Do Not Disturb If the leader's presence is set to Do Not Disturb, a call forwarded to the leader does not ring the leader's phone but automatically rings the phones of all other team members. After the call is answered, all team phones stop ringing. If the call is unanswered, it is forwarded to the leader's voicemail. If the caller has permission to break through to the leader, the leader's phone rings and the call is not forwarded to other team members.
Ring Team when Leader Status Is Set to Offline If the leader's presence is set to Offline, a call forwarded to the leader does not ring the leader's phone but automatically rings the phones of all other team members. After the call is answered, all team phones stop ringing. If the call is unanswered, it is forwarded to the leader's voicemail.
Calls from Specific Callers Do Not Go to Team Calls from contacts whom the leader has designated as Personal are never forwarded to team members.

Group Chat
OCS 2007 R2 Group Chat enables users to engage in persistent, ongoing IM conversations. Group Chat differs from Group IM in that the latter is not persistent. After a Group IM session has ended, its state is lost.
With OCS 2007 R2 Group Chat, however, the conversation persists, along with all IM conversations, files, Web links, and other associated data. This persistence makes it possible to maintain complete records of each session. It also enables the instant exchange of business expertise across an organization and with external partners in a way that makes it possible to maintain a continuing flow of information among project members.
Group Chat requires the deployment of three components that are new with OCS 2007 R2:
OCS 2007 R2 Group Chat Server This gives users access to Group Chat functionality.
OCS 2007 R2 Group Chat Administration Tool This tool enables an Office Communications Server administrator or delegate to manage chat rooms and users. An administrator can create categories and group channels, define their scope and membership, manage how users can use the group channels, and specify which users are administrators and managers.
Office Communicator 2007 R2 Group Chat This is a desktop client application that makes chat room conversations and features available to end users and that enables users to send and receive instant messages, either in a chat room or singly with another user outside the chat room. To use chat rooms, this component must be installed in addition to Office Communicator.
Figure 1 shows all of the components of a topology with a single Group Chat Server and optional Compliance Server with a separate compliance database. Figure 2 shows a multiple-server Group Chat topology.
Figure 1 Single-server Group Chat topology
Figure 2 Multi-server Group Chat topology
With OCS 2007 R2 Group Chat, end users can perform the following tasks:
  • Create a chat room, which is a persistent topic that users can join
  • Restrict chat room access to selected users
  • View all chat rooms in which the user is a member
  • Join a chat room
  • View and read chat room messages
  • Post messages to a chat room
  • Post Web links to a chat room
  • Receive notifications when a user is added to a chat room or contact list
  • Customize the chat room display
  • Log chat room content
  • Review chat room logs
  • Create an auditorium chat room, where only certain members can post messages
  • Send and receive instant messages without creating a chat room
  • Save instant messages to a text file
  • Archive chat room content and IM conversations
  • Choose whether to use Communicator or the chat room's client for IM conversations. This decision is important because choosing one of the clients makes IM conversations unavailable on the other client

Desktop Sharing
Desktop sharing enables users to transmit views of their desktops to others. With the new Web-based client in OCS 2007 R2, users can initiate desktop sharing during any Web conference that the server hosts. The desktop-sharing client is based on and integrated with the 2007 R2 release of the Microsoft Office Communicator Web Access client.
The new desktop sharing client can be initiated by using the 2007 R2 version of the Communicator Web Access client, Office Communicator 2007 R2, Microsoft Office Live Meeting 2007 R2 (in meetings hosted by Office Communications Server instead of the Live Meeting service), and Microsoft Office SharedView. A desktop sharing session can also be initiated by using a Web browser to navigate to the desktop sharing Web site hosted by the Communicator Web Access server. Desktop sharing requires installation of the Microsoft Office Communicator Web Access plug-in.
Users running a supported client on a computer running Windows can initiate sharing, view, or take control of programs during a desktop sharing session. Users participating in a desktop sharing session using an Apple Macintosh or a computer running the Linux operating system can view or take control of programs but cannot initiate sharing.
By using a supported client, users can initiate a desktop sharing session and invite other users, including users that are not enabled for Unified Communications (UC). Communicator Web Access and Office Communicator users can start desktop sharing during an existing IM conversation or audio/video conference. Communicator Web Access automatically generates a meeting URL for new participants at the time the desktop sharing session is initiated. Members of a distribution group can be added to a desktop sharing session. Users outside the organization's network can also join a desktop sharing session if Communicator Web Access is configured for external access.
Depending on policy, the user hosting a session can give control to other participants, deny control, retake control, or stop the session. While in a desktop sharing session, all users can send instant messages to other participants.
Anyone in the session can add audio conferencing to a desktop sharing session if the environment has been configured with an A/V Conferencing Server and if the environment supports calls to the Public Switched Telephone Network (PSTN). When audio is added, Communicator Web Access initiates a call to the user's telephone, and then it calls the telephone numbers of other users in the session to add them to the audio conference. Conference Attendant Console users can participate in the audio conference portion of a desktop sharing session.

Server Applications to Extend Voice and Conferencing
OCS 2007 R2 ships with several applications which extend and enhance the server's existing voice and conferencing functionality. These applications run on the OCS 2007 R2 Application Server, which is installed on the same computer as the Enterprise Edition front-end server or Standard Edition Server.
Dial-In Conferencing Feature Dial-in conferencing enables anonymous users and enterprise users who want or need to use a PSTN phone to join the audio portion of an on-premise conference. Conferencing Attendant is an application that is run to enable this dial-in conferencing feature, and the Conferencing Announcement Service is an application that enhances this feature by providing announcements when users join or leave a conference.
Conferencing Attendant OCS 2007 R2 Conferencing Attendant is an application that enables users to join an A/V conference by dialing in using a telephone on the PSTN. Conferencing Attendant can be installed to provide audio conferencing capabilities to phone users without requiring the services of a third-party Audio Conferencing provider. Conferencing Attendant also requires that the 2007 R2 release of Communicator Web Access be installed to provide the Dial-In Conferencing Web page, which users can access to manage their reservationless meeting information and personal identification number (PIN).
Conferencing Attendant provides user management of reservationless meeting information and PIN management through a Dial-In Conferencing Web page, support for multiple languages, music-on-hold, conference scheduling using an Outlook add-in, support for both anonymous and remote users, reservationless meetings, and configurable access phone numbers.
Conferencing Announcement Service Conferencing Announcement Service uses a tone to announce when a phone user joins or leaves a conference. If the conference organizer dials out to a user with a request to join the conference, a tone plays when the user joins. Conferencing Announcement Service also announces when a phone user has been muted or unmuted. If you run Conferencing Attendant without also running Conference Announcement Service, there are no announcements for phone users.

Response Group Service
OCS 2007 R2 Response Group Service enables administrators to create and configure one or more small response groups for the purpose of routing and queuing incoming phone calls to one or more designated agents. These response groups can be deployed in departmental or workgroup environments and in entirely new telephony installations.
Typical usage scenarios include an internal help desk, customer service desk, or general external call handler. Response Group Service can increase response group usage and reduce the associated overhead by pushing the tasks of response group maintenance down to the users who directly benefit from them.
Response Group Service works with Office Communicator and the new Office Communications Server Attendant. Response Group Service also supports incoming calls from the local carrier network. Agents can use Communicator, Communicator Phone Edition, or Office Communications Server Attendant. Figure 3 shows the Response Group Service deployed on Office Communications Server 2007 R2 Enterprise Edition servers in a consolidated configuration. In this example, calls from on-site and remote callers can be distributed to on-site and remote callees.
Figure 3 Response Group Service deployment
Response Group Service includes the following features:
Supported Call Routing Algorithms Response Group Service supports standard response group call-routing algorithms, including serial, longest-idle, parallel, and round robin. Routing algorithms are configured for each defined group of agents.
Interactive Voice Response (IVR) Call navigation employs IVR, which detects and recognizes both speech and dual-tone multi-frequency (DTMF) keypad input. Response Group Service IVR also supports text-to-speech and the WAV file format. The administrator can update IVR prompts.
Call Queuing Calls are queued pending the availability of an agent configured to accept the call.
Music-On-Hold Callers are put on music-on-hold until an agent becomes available. Presence-based routing Call routing takes agent presence status into account. The routing component would skip, for example, agents who are signed out or busy.
Presence-based routing Call routing takes agent presence status into account. The routing component would skip, for example, agents who are signed out or busy.
Response Group Templates Predefined response group templates make it easy for an administrator to create a new response group. The administrator uses the response group template to define the usage experience of the call, including questions asked to the caller, options given to the caller, music-on-hold options, and configuration of business hours and holidays.
User Management Using a Web-based tool, administrators assign management responsibility for a response group (basic or enhanced hunt groups only) to any user. The user is thereby empowered to configure and manage the response group, including configuring music-on-hold and defining business hours. As a result, user management puts control over response groups in the hands of people who actually use them, while relieving administrators of much of the overhead associated with managing traditional response groups.
Agent Types Response Group Service supports both formal and informal agents. Formal agents are required to sign in or sign out of response groups. They might include someone who fills in when colleagues are on vacation or lunch breaks or perhaps include separate groups of people who take calls at different times of the day. Informal agents are not required to sign in or out of response groups.
Simplified Management Response Group Service simplifies management of response groups by providing a Web-based response group deployment and configuration tool, a standalone Microsoft Management Console (MMC) 3.0 snap-in (which can be opened from OCS 2007 R2), and support for end users configuring and managing response groups.

Outside Voice Control
Outside Voice Control provides Enterprise Voice functionality and call control to mobile phones that are not otherwise enabled for Enterprise Voice. Microsoft Office Communicator Mobile clients can receive or make calls by using a single enterprise number or Session Initiation Protocol (SIP) Uniform Resource Identifier (URI).
Unanswered calls are directed to the user's single Enterprise Voice mail repository. Users of devices that are running Office Communicator Mobile clients can use the voice functionality of that device as if it were part of the enterprise network, rather than the carrier network, by providing a callback number to the server.

SIP Trunking
OCS 2007 R2 simplifies and reduces the cost of deploying Enterprise Voice by enabling an enterprise to connect its voice network to a service provider offering PSTN origination, termination, and emergency services. This capability, known in the telecommunications industry as SIP trunking, enables enterprises to not deploy IP-PSTN gateways, with or without Mediation Servers, to enable PSTN connectivity. In other words, it offers a generic means for an IP PBX to connect to a remote hosted service for the purpose of originating and terminating calls to the PSTN network.
Figure 4 depicts the SIP trunking topology in OCS 2007 R2. As shown in the diagram, an IP virtual private network (VPN) is used for connectivity between the enterprise network and the PSTN service provider. The purpose of this private network is to provide IP connectivity, security, and (optionally) Quality of Service (QoS) guarantees.
Figure 4 The SIP trunking topology
In such an environment, it is not required to additionally secure the SIP signaling traffic (with Transport Layer Security, or TLS) or the media traffic (with Secure Real-Time Protocol, or SRTP). Connections between the enterprise and the service provider therefore consist of plain TCP connections for SIP and plain RTP (over UDP) for media potentially tunneled through an IP VPN.
It's expected that the demarcation point in most service providers' networks will be a session border controller, although this is not required. Likewise, whether to use an IP-PSTN gateway or softswitch in the service provider network is up to the service provider.
In this SIP trunking topology, the Mediation Server performs media and signaling translation, just as it does when connected to an enterprise IP-PSTN gateway. All SIP traffic and media traffic between the enterprise network and the service provider network flows through the VPN and through the Mediation Server.
The Mediation Server can discover the service provider proxy (the Session Border Controller in Figure 4) either through static provisioning or DNS query against an FQDN published by the PSTN service provider. The PSTN service provider can use either of these methods for discovering the list of enterprise proxies (Mediation Servers) to which it can connect.
The OCS 2007 R2 SIP trunking capability enables two key scenarios. In the first scenario, an enterprise user inside or outside the corporate firewall can make a local, long distance, or emergency call (specified by an E.164-compliant number that is terminated on the PSTN as a service of the corresponding service provider). In the second scenario, any PSTN subscriber can contact an enterprise user inside or outside the corporate firewall by dialing a Direct Inward Dialing number associated with that enterprise user.

Enhanced Media
Improved A/V collaboration is the centerpiece of OCS 2007 R2. Fundamental to this effort is an improvement in overall user experience both during phone calls and conferences. Among the media enhancements that have been implemented to achieve this goal are the following:
Improved Media Resiliency End users can expect to have reliable voice communications that continue working even if transient network conditions cause signaling failure in an Office Communications Server component. If a user's attempt to establish a new media connection fails, such as during an attempt to add video to an existing voice connection, Office Communicator 2007 R2 automatically tries to restore this connection in the background without further user involvement. (Note that if a signaling failure occurs for the duration of the all after it has initially been established, call control features such as hold, retrieve, and transfer will not work.)
Improved Voice Quality Overall voice quality is significantly better for OCS 2007 R2. Some of the more notable changes include suppression of typing noise during calls, improved generation of "comfort noise" (reducing hissing and smoothing over the discontinuous flow of audio packets), better echo detection and reduced echoing at the beginning of a call, better regulation of audio volume among peer-to-peer callers and conference participants, and improved codec selection for calls to the PSTN over low-latency connections.
High-Definition and VGA Video High-definition (HD) video (resolution 1270 x 720; aspect ratio 16:9) and VGA video (resolution 640 x 480; aspect ratio 4:3) are supported for peer-to-peer calls between users running Office Communicator 2007 R2 on high-end computers. The resolution that each participant views in a single conversation may differ, depending on the video capabilities of their respective hardware. (See the "Video Negotiation" sidebar.)
HD and VGA video are not supported for conferences. Administrators can set policies to restrict or disable HD or VGA video on clients, depending on computer capability, network bandwidth, and the presence of a camera able to deliver the required resolution. These policies are enforced through in-band provisioning.

Simplified Firewall Configuration for the A/V Edge Server
OCS 2007 R2 simplifies firewall configuration for the A/V Edge Server to support audio and video scenarios involving remote users and federated users. In OCS 2007 R2, the perimeter network's external firewall needs to be configured to enable inbound and outbound connections with the public Internet to the A/V Edge Service on ports 3478 for User Datagram Protocol (UDP), 443 for Transmission Control Protocol (TCP), and 50,000 -59,999 for both UDP and TCP.
If application sharing does not need to be enabled for federated scenarios, then with OCS 2007 R2, the perimeter firewall can be configured to enable only inbound connections from the public Internet to the A/V Edge Server on ports 3478 for UDP and 443 for TCP. This reduced port range for inbound connections simplifies the configuration changes required on the external firewall. However, if application sharing needs to be enabled in federated scenarios, then ports 50,000-59,999 need to be opened for outbound TCP connections.
In OCS 2007, the external IP address of the A/V Edge Server has to be publicly routable and not located behind a Network Address Translation (NAT). In Communications Server 2007 R2, if a public IP address is not available, the A/V Edge Service can be deployed behind a NAT as part of a single Edge Server topology. (It's important to note that a publicly routable IP address is required if the topology contains multiple load-balanced A/V Edge Servers.)

Archiving, CDR, and QoE Enhancements
Office Communications Server 2007 R2 delivers enhanced out-of-the-box monitoring and reporting capabilities for new features and scenarios while simplifying the deployment and administration of monitoring components. Archiving, Call Detail Records (CDR), and Quality of Experience (QoE) enhancements for Office Communications Server 2007 R2 include:
  • CDR and archiving data for new scenarios and features, including Call Delegation, Team Calling, and Response Group Service.
  • New CDR usage reports provide system usage details for conferencing, voice and video, and IM.
  • New QoE metrics for audio quality, PSTN connections, and network connectivity. These new QoE metrics provide better-quality monitoring and diagnostics. Furthermore, QoE reports have been fully redesigned and enhanced with the new metrics.
  • A new Office Communications Server role, the Monitoring Server, gathers both CDR and QoE data.
  • The OCS 2007 R2 Archiving Server now performs only IM conversation archiving-related functions.
Video Negotiation
Video negotiation is a process whereby an endpoint proposing to send video can determine the video capabilities of the receiving endpoint prior to sending the video stream. The purpose of video negotiation is to make sure that the sending endpoint can produce and send a given resolution and that the receiving endpoint can receive and render that same resolution. The negotiation follows an offer/answer model until common agreement is found. The highest-quality video capability held in common is used in peer-to-peer calls unless the user at the receiving end prefers a lower resolution or frame rate.
An endpoint's video capability is based on several qualities, including central processing unit (CPU), available memory, attached devices, and network resources. For example, a user may have a camera that can send VGA video at 15 frames per second (fps) or Common Intermediate Format (CIF) video at 30 fps, but that cannot handle high-definition (HD) video. Video negotiation always resolves to CIF at 15 fps for multiparty video conferencing.
The video preference of the user at the receiving endpoint also helps to determine the final negotiated format. For example, a user may want to select a smaller video window even though the negotiated video settings enable a higher resolution. In such cases, the receiver instructs the sender to adopt a lower video format. The ability to specify video preferences in this way prevents inefficient use of bandwidth. Office Communicator offers three window sizes and therefore three preference settings: small, large, and full screen.

Simplified Management
Office Communications Server 2007 R2 reduces management overhead and simplifies deployment and ongoing operations. These management improvements include the following:
Simplified Topologies The recommended topology for Office Communications Server 2007 R2 is a consolidated configuration in which all server roles in a pool are collocated on a single computer. Response Group Service, Conferencing Auto-Attendant, Conferencing Announcement Service, and Outside Voice Control are also collated on a single computer. All Edge Server roles in a perimeter network are collocated on a single computer. As a result, both deployment and operational overhead are reduced, thereby reducing cost of ownership. Scalability is achieved by adding computers to the pool or perimeter network and load balancing them.
Enhanced Administrative Snap-In The Administrative snap-in has been updated for Office Communications Server 2007 R2 to include Application Server, Response Group Distributor, Conference Attendant, Conference Announcement Service, Call Control Service, and Application Sharing Conferencing Server.
The new snap-in enables administrators to configure and manage each of these new components by using a familiar interface. In addition, these new components appear in the server-by-role view in the snap-in.
Conference Directories Conference Directories are new entities that provide persistent identities to scheduled conferences. When a scheduled conference has to be moved to a new pool—for example, when its original pool is taken offline—the scheduled conference retains the identity that its Conference Directory provided. Conference Directories, including those that are as yet unassigned, are listed in the tree view of the administrative console.
Automatic Updates Administrators can push updates to Office Communicator 2007 R2, Communicator Phone Edition, and the RoundTable without relying on the refresh cycles of other administrators and with little or no involvement from users.
Improved Certificate Wizard An improved Certificate Wizard enables administrators to create multiple certificate requests offline for the same computer and then send them to an enterprise or public certificate authority (CA). After certificates are imported, the Certificate Wizard enables the administrator to specify the certificate assignments to specific services. The Certificate Wizard also warns when Subject Alternate Names (SANs) include spaces and special characters, which are not allowed.
Optional Installation of Administrative Tools Installation of the Office Communications Server 2007 R2 Administrative snap-in is now optional. The Communicator Web Access administrative snap-in and the deployment command-line tool LcsCmd are also no longer installed by default.
Planning Tool The Planning Tool for Office Communications Server 2007 R2 provides prescriptive guidance for planning and deployment. The Planning Tool is a wizard that asks a series of questions about features of interest, information about your organization, and anticipated capacity.
Based on the answers you provide, the Planning Tool creates a recommended topology for each of your organization's main sites, specifies recommended hardware, and prescribes the planning and deployment steps to implement the topologies. The Planning Tool takes about 10 minutes to complete, depending on the complexity of your organization.

Stephanie Pierce is a Senior Technical Writer on the Microsoft Office Communications Server User Assistance team and former Program Manager of the Unified Communications Group.


Office Communications Server
How Remote Call Control Powers OCS 2007 R2
Rajesh Ramanathan
At a Glance:
  • What Remote Call Control can do
  • How RCC works
  • Common OCS scenarios for implementing RCC

Contents
The CSTA Standard
Bootstrapping the RCC Channel
The Basic MakeCall Flow
The Basic Answer Call Flow
RCC and Presence Integration
RCC and Conferencing
RCC in Enterprise Voice with PBX
The Limitations of RCC
This article is a continuation of the series covering how Office Communications Server (OCS) 2007 provides unified communication, Voice over IP (VoIP), and conferencing features. Here I'll discuss how Office Communications Server provides the Remote Call Control (RCC) feature with legacy PBXs and how various call-related scenarios can be supported using RCC. I also touch briefly on the dual forking configuration and how RCC can be used in that configuration to provide a flexible option for the user to make and receive calls from either Office Communicator or the PBX phone.
In my article "How Presence Powers OCS 2007," I gave an overview of the OCS 2007 solution, explaining how various pieces fit together. I also explained how presence plays a key role in the unified communication and how it is used for effectively routing voice calls. In "How Voice Powers OCS 2007," I discussed how OCS provides VoIP capabilities. I also took a brief look at various configuration options for a user, focusing on Enterprise Voice configuration.
Another configuration I briefly touched upon was RCC, which shipped with Live Communication Server 2005 and allows Office Communicator 2005 to control calls from the PBX phone. With OCS 2007, this feature is still available as an alternate configuration when there is an existing PBX deployment. There is also an option to enable RCC with Enterprise Voice, where users can use both the PBX phone as well as Office Communicator to manage their calls.
RCC is the ability to send or receive calls on a device other than your computer. For OCS, this means the following:
  • When the PBX phone rings, an alert appears in Communicator that allows you to answer the call.
  • When someone's phone number is clicked on Communicator, the PBX phone goes off-hook in speakerphone mode and dials the number.
  • Call forwarding can be set on the PBX phone.
  • Incoming calls to the number can be deflected to other phone numbers.
  • Mid-call control events, such as Single Step Transfer and Consultative Transfer, can be performed on a call on the PBX phone. DTMF signals can be sent from the PBX phone using UI in Communicator.
Figure 1 The RCC configuration
One of the big differences between RCC and Enterprise Voice configuration is that in the RCC configuration, Office Communicator clients just have signaling controls set up with the PBX—there is no VoIP call sent to the Office Communicator clients. In other words, Office Communicator is not being used as a softphone in these configurations.
In the simplest configuration, RCC can be deployed by setting up a SIP/CSTA Gateway between the PBX and OCS. The SIP/CSTA Gateway provides a Session Initiation Protocol (SIP) interface toward the OCS side and uses Computer-Supported Telecommunications Application (CSTA) signaling messages wrapped inside of SIP messages to communicate with Office Communicator clients.
Toward the PBX side, the SIP/CSTA gateway uses proprietary PBX vendor-specific signaling interfaces. As you can see in Figure 1, RCC deployments leverage the public switched telephone network (PSTN) connectivity that is provided by the PBX to make calls out to the PSTN world. Such deployments also leverage the voicemail system that is attached to the PBX.
Figure 2 shows the logical diagram of how voice calls fit into an RCC system. As you can see, the Office Communicator client creates a signaling session where call control messages that are based on the CSTA protocol flow between the Office Communicator client and the SIP/CSTA gateway. The actual call itself is between the PBX desk phone and the remote endpoint, which can be another PBX desk phone or a PSTN endpoint—or even another Enterprise Voice-enabled user on an OCS phone.
Figure 2 Calls in an RCC configuration

The CSTA Standard
RCC implementation in Office Communicator is based on the European Computer Manufacturers Association (ECMA) Technical Report-87 (TR-87). This is a SIP implementation of the CSTA model also proposed by ECMA. Another standard, ECMA 323, provides the detailed schema of the XML messages that are sent in the SIP channel for a CSTA implementation. Office Communicator follows a subset of the capabilities and methods in TR-87. More detailed documentation about support for the CSTA standard in Communicator is available through the Microsoft Connect program. Note that throughout the rest of this article, CSTA refers to the generic protocol that is used between Office Communicator clients and the PBX.

Bootstrapping the RCC Channel
In the "How Presence Powers OCS" article, I explained how the SIP Uniform Resource Identifier (URI) is an important part of the OCS system and how each user is assigned a SIP URI that allows calls to be routed to the user. When Office Communicator clients talk to a SIP/CSTA Gateway, they need to identify what phone Office Communicator needs to control. This phone number is identified as a Line URI, which is basically a telephone number in RFC 3966 format. This Line URI property is stored in Active Directory in the user's record and is made available to Office Communicator as part of inband provisioning.
During startup, Office Communicator clients also need to connect to the SIP/CSTA gateway (which is addressed as defined by the Server URI in the user configuration in OCS) to set up a persistent INVITE channel. Communicator knows about the RCC capability and the Server URI using the inband provisioning mechanism (also explained in the article "How Presence Powers OCS").
The RCC system follows a command/response model. Each message that Office Communicator sends to the SIP/CSTA Gateway contains a command encoded as an XML (ECMA 323) payload. Each response or notification from the SIP/CSTA Gateway also contains an XML (ECMA 323) payload. The first SIP INVITE creates the session and contains a RequestSystemStatus CSTA message. The SIP/CSTA Gateway accepts the request and responds with a RequestSystemStatusResponse in the 200 OK (see Figure 3).
Figure 3 Invite model with SIP/CSTA Gateway
Notice that there is no BYE corresponding to the INVITE. This is because the INVITE is set up as a long-lasting session on which subsequent commands from Office Communicator can be sent or notifications received from the SIP/CSTA Gateway.
Once the INVITE/200 OK sequence is completed, Office Communicator queries the capabilities of the SIP/CSTA Gateway (which relates to capabilities of the PBX) to discover the supported feature set. And then it initiates monitoring on the phone line.
Querying the capabilities of the PBX is an important step in bootstrapping—depending on what features are supported on the PBX/CSTA Gateway, various UI elements in Office Communicator may be disabled or may not be available at all. For example, if the Single Step Transfer feature is not supported on the SIP/CSTA Gateway, Office Communicator will not show the transfer button for a call in the call controls.
Thus an RCC configuration requires two parameters that are consumed by the Office Communicator clients. First is Server URI, which is a SIP URI that contains the address of the SIP/CSTA gateway and allows the Office Communicator clients to connect to the server by issuing an SIP INVITE to the URI. (This URI is usually of the form gateway@contoso.com.)
Second is Line URI, which is a TEL URI that uniquely identifies the phone number in the PBX system. This URI follows the RFC 3966 format (for instance, TEL:+14255551212 or TEL:4255551212;ext=1212).
Once the initial bootstrapping is completed, Office Communicator receives events from the PBX whenever a status change occurs on the monitored phone line as specified by a telephone number. When Office Communicator needs to originate or answer a call, it sends an INFO message that contains CSTA XML messages to the SIP/CSTA Gateway. Events received from the SIP/CSTA Gateway also contain CSTA XML messages embedded within SIP INFO messages (see Figure 4 for an example).
Figure 4 INFO message and 200 OK response
INFO sip:gateway@contoso.com SIP/2.0
From: <sip:alice@ocs.contoso.com>;tag=31424bf782;epid=77e47b4782
To: <sip:gateway@ocs.contoso.com>;tag=1fbe74b0
Call-ID: 52c4a528322d4457a486283ccf78b696
User-Agent: UCCP/2.0.6362.0 OC/2.0.6362.0 (Microsoft Office Communicator)
Content-Disposition: signal;handling=required
Content-Type: application/csta+xml
Content-Length: 277
<?xml version="1.0"?>
<MakeCall xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
  <callingDevice>tel:+14255551212;ext=1212</callingDevice>
  <calledDirectoryNumber>tel:+14258828080;ext=5555</calledDirectoryNumber>
  <autoOriginate>doNotPrompt</autoOriginate>
</MakeCall>

SIP/2.0 200 OK
From: <sip:alice@ocs.contoso.com>;tag=31424bf782;epid=77e47b4782
To: <sip:gateway@ocs.contoso.com>;tag=1fbe74b0
Call-ID: 52c4a528322d4457a486283ccf78b696
Content-Disposition: signal;handling=required
Supported: 100rel,replaces,timer
User-Agent: Example Gateway Release 1.0 version 4.2.3
Contact: <sip:gateway@ocs.contoso.com>
Content-Type: application/csta+xml
Content-Length: 247
<?xml version="1.0" encoding="UTF-8"?>
<MakeCallResponse xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
  <callingDevice>
    <callID>17772</callID>
    <deviceID> tel:+14255551212;ext=1212</deviceID>
  </callingDevice>
</MakeCallResponse>
Note that OCS serves as a SIP Proxy in this scenario. Any signaling messages between Office Communicator clients and the SIP/CSTA Gateway are passed through transparently by the OCS server. To ensure that the SIP/CSTA Gateway is running and the signaling link is available, Office Communicator refreshes the INVITE dialog every 10 minutes by sending a Re-INVITE with the RequestSystemStatus command.

The Basic MakeCall Flow
The sequence of making a call is highlighted in Figure 5. The user can make a call to a number by typing in the number in the Office Communicator search box or by selecting the phone number of a contact from the click-to-call list. When the user selects to call a number, Office Communicator issues a MakeCall command to the SIP/CSTA Gateway that contains the phone number that is selected for the call. The RCC interface only lets users make calls to the phone numbers. When the user selects the Communicator Call option to call someone, Office Communicator originates a VoIP call to the remote user's SIP URI.
Figure 5 Making a call
The message sequence in Figure 5 shows how the SIP/CSTA Gateway translates a MakeCall command into proprietary PBX messages; the PBX phone goes off-hook and places a call to the selected phone number.
Notice that the interface to the SIP/CSTA Gateway provides elaborate mechanisms to indicate various states of the phone. In this example, you can see that there are multiple events being received by Office Communicator that indicate the activity on the PBX phone. These start with the OriginatedEvent (indicating that the PBX phone is originating an outgoing call) to the DeliveredEvent (indicating a Ringing state). By the time a DeliveredEvent is received, it is possible that a media path for playing ringback sounds has already been established between the phone and the remote user.
When the call is finally answered, the PBX sends the appropriate signals to the SIP/CSTA Gateway and an EstablishedEvent is sent to Office Communicator indicating that the call has been answered (see Figure 6).
Figure 6 The call has been answered

The Basic Answer Call Flow
When a call comes into the PBX system, the PBX informs the SIP/CSTA Gateway, which in turn originates a DeliveredEvent CSTA notification sent to Office Communicator (see Figure 7). Once Office Communicator receives the DeliveredEvent notification, the incoming call notification is shown to the user.
Figure 7 Answering a call
Office Communicator also performs Reverse Name Lookup (RNL) against the Address Book Service and Microsoft Office Outlook contacts of the user to show a display name for the corresponding caller. The user can now answer the call from the notification, resulting in an AnswerCall CSTA command to the SIP/CSTA Gateway. At this point, the SIP/CSTA Gateway converts the AnswerCall to an appropriate PBX specific answer message and the two-way media channel is set up between the caller and the PBX phone.

RCC and Presence Integration
With the RCC integration, a user's phone status is now integrated with presence. For example, whenever the user is in a call on the PBX, Office Communicator will change the user's status to In a Call. This status can be viewed on other users' Office Communicator clients. Additionally, users can publish their personal phone numbers through presence so other people can call them on their home or mobile numbers through Office Communicator.
But note that when the Office Communicator 2007 presence is set to Do Not Disturb, the PBX system's Do Not Disturb capability isn't triggered. A user must manually manage the Do Not Disturb state on the PBX system.

RCC and Conferencing
When in an RCC call, Office Communicator 2007 does not allow the user to add another user to the call using Office Communicator. However, users can still create a conference on the PBX phone by using the PBX phone's conferencing capability. When this occurs, Office Communicator continues to show the call as a peer-to-peer call, instead of a conference call.
Similar to the escalation to three-party scenario, incoming conference calls on the PBX phone appear as peer-to-peer calls on Office Communicator and can be answered as peer-to-peer calls on Office Communicator.

RCC in Enterprise Voice with PBX
RCC can be used in the Enterprise Voice scenario with PBX integration (also known as dual forking). In an Enterprise Voice with PBX integration scenario, both the PBX and OCS systems fork calls toward each other to allow the user to use either the PBX phone or the Office Communicator softphone to answer calls. This option allows users to leverage all the benefits of Enterprise Voice.
The Enterprise Voice with PBX integration scenario with RCC added on provides a unique experience: users are able to answer an incoming call on the phone or on Office Communicator from a single incoming call notification in Office Communicator (see Figure 8).
Figure 8 Choosing an endpoint to answer an incoming call
In addition, users with notebook computers can use Office Communicator as a softphone to make calls when outside corporate premises. User even have the ability to create conference calls from Office Communicator by leveraging the conferencing capabilities provided by the Office Communication Server A/V multipoint control units (MCUs).

The Limitations of RCC
RCC provides an easy way for achieving integration with an existing PBX deployment. However, an RCC-enabled user's capabilities are limited by what the wired PBX phone can do. For example, an Enterprise Voice user can leverage native OCS support for outside voice capabilities and make and receive VoIP calls from both inside and outside the organization.
Enterprise Voice scenario also enables several presence features that OCS provides (such as Presence access levels to Team, allowing urgent interruptions during Do Not Disturb). An RCC-only user will not have access to these features. In addition, other features, such as escalating two-party conferences to a multi-party conference, are also only supported with Enterprise Voice users.
In an RCC system, the PBX is the master of the call-handling rules. Therefore, any settings or rules that divert calls automatically or send these to a shared line are actually controlled at the PBX. New features available to an Enterprise Voice user, such as Simultaneous Ringing and the Delegation feature introduced with OCS 2007 R2, are not available for an RCC-only user.
RCC configurations are designed to be limited to a PBX deployed in a single location. This is why multiple location-specific dialing rules are not supported for RCC topology. In contrast, an Enterprise Voice configuration allows multiple locations to be specified and users in specific locations receive number normalization rules that are specific to their locations.
Nevertheless, RCC offers a handy way to provide telephony features with OCS in certain scenarios. While it offers a limited feature set compared to Enterprise Voice, when used within an Enterprise Voice configuration (for dual forking), RCC can give users a rich set of OCS features along with the flexibility to make and receive calls from either a desk phone or Office Communicator.

Rajesh Ramanathan works as Lead Program Manager on the Office Communicator team. He has worked in communications for 15 years and has designed voice protocols, user experiences, and voice and conferencing experiences for Office Communicator 2007 R2. He can be reached at rajeshra@microsoft.com.


Office Communications Server
Securing OCS with ISA Server
Alan Maddison
At a Glance:
  • OCS 2007 R2 Edge Server roles and topologies
  • Configuring ISA Server in a 3-Leg Perimeter network
  • Understanding OCS certificate requirements
  • Creating a Web listener and a reverse proxy for OCS

Contents
Edge Servers
Getting Ready
Configuring ISA Server 2006
A Word about Certificates
Reverse Proxy
Last Words
Office Communications Server (OCS) 2007 R2 provides powerful capabilities that allow you to extend your Unified Communications infrastructure to users outside of your organization. This can have tremendous benefits. Functionality such as Web and audio/visual (A/V) conferencing, for example, can improve an organization's responsiveness and effectiveness in its daily business tasks.
If you choose to deploy OCS functionality to remote users and partners, however, you must complete two important steps. First, you will need to deploy OCS Edge Servers to best practices defined in the Office Communications Server 2007 R2 Security Guide. Second, you will need to provide reverse proxy access to the Edge Servers. In this article I'll take a look at using ISA Server 2006 with SP1 to secure your OCS deployment.

Edge Servers
To communicate with other OCS infrastructures and to allow remote access to your organization's network, you need to deploy one or more Edge Servers in your perimeter network (also known as a DMZ) so that users outside the firewall can gain secure access to your internal OCS deployment. OCS 2007 R2 includes three Edge Server roles, summarized in Figure 1, which also describes reverse proxy functionality.
Figure 1 Edge Server roles and reverse proxy for OCS 2007
Role | Purpose
Access Edge Server | Authenticated external user access including public IM connectivity, federation, Web conferences, and voice functionality.
Web Conferencing Edge Server | External Web conferencing and data collaboration.
A/V Edge Server | Any external user access to A/V conferences and point-to-point A/V calls.
Reverse Proxy | Group expansion, address book file download, Web conferencing download of meeting content.

Prior to the R2 release of Office Communications Server 2007, Microsoft supported four different Edge Topologies that provided varying levels of sophistication and scalability. In general, the topologies differed in the location of the various Edge Server roles:
  • Consolidated Edge Topology
  • Single-Site Edge Topology
  • Scaled Single-Site Edge Topology
  • Multiple Site with a Remote Site Edge Topology
With the release of R2, Microsoft now require that all roles run on the same server with scalability provided by hardware load balancers (the Network Load Balancer, or NLB, component available in Windows is not supported). A Consolidated Edge Topology is a cost-effective approach that has the added benefit of being the simplest to deploy and administer. This topology works for all organizations, and for the purposes of this article I'll focus on this design.
An important point to remember is that in addition to changes in OCS topology support, there have been some significant changes in the network topologies and technologies supported by R2. However, in R2 the A/V Edge Server role must have a public IP address on the external network interface card (NIC) due to the underlying requirement of the Simple Traversal of UDP through NAT (STUN) protocol.
Though Microsoft has been very adamant about this requirement, many Administrators have ignored the documentation and have attempted to implement the OCS Edge Servers in a Network Address Translation (NAT) environment. If you implement NAT in front of your A/V Edge Servers, your users could experience intermittent connectivity problems and may not even be able to establish a connection.
One important point to remember is that as of R2 Microsoft no longer supports Destination Network Address Translation (DNAT) in an OCS environment. This means that the firewall or Load Balancer must be configured with Source NAT (SNAT) before introducing R2 into your environment. Finally, your Edge Servers should not be members of an Active Directory domain.
If the Edge Servers are not configured correctly, you will only be creating more of a headache for yourself when ISA Server is thrown into the mix. Review, validate and test your Edge configuration before moving on.
Figure 2 3-Leg Perimeter deployment of Consolidated Edge Servers

Getting Ready
To deploy the OCS Edge Topology, I'll focus on a common implementation scenario in which a firewall, ISA Server in this case, is deployed in a 3-Leg Perimeter network; a simple, cost-effective approach that shares core concepts with more complex firewall topologies. In this design, the three legs correspond to the internal network, the perimeter network, and the external (Internet) network. This approach not only allows external user access to the OCS infrastructure, it also supports using ISA Server in a reverse proxy role.
Figure 2 depicts a logical view of an ISA Server 3-Leg implementation. Before beginning to configure ISA Server, it is a good idea to have already laid out the IP addressing and Fully Qualified Domain Name (FQDN) mappings for your Edge Servers and ISA Server. This will make the configuration process a lot simpler and quicker.
Figure 3 shows an example of a suitable check list. Note that I have used a private IP address range for informational purposes only; you will have to use public IP addresses.
Figure 3 Sample configuration
Role | Fully Qualified Domain Name | Public IP Address | NIC | External User Port Requirements | Internal User Port Requirements
Access Edge Server | sip.contoso.com | 172.16.0.2/29 | External | 5061,443 | 5061
A/V Edge Server | av.contoso.com | 172.16.0.3/29 | External | 443,3478 50,000-59,999 | 443, 5062 50,000-59,999
Web Conferencing Edge Server | webconference.contoso.com | 172.16.0.4/29 | External | 443 | 8057

Figure 4 shows the IP addressing information for the ISA Server, including the IP address used to publish (reverse proxy) the OCS Address Book and Content Web site used by the Web Conferencing Server.
In a Consolidated Edge Deployment, there is typically a single physical server with two NICs, one for internal traffic and one for external traffic. The NIC connected to the corporate network (internal) will have an IP address from your existing internal IP address range. The NIC that connects to remote users (external) will use at least one public (fully routable) IP address for the A/V Edge Server. Although not strictly necessary, it is simpler to also assign public IP addresses to the other Edge roles, as in Figure 4.
Figure 4 ISA Server IP addresses
ISA Interface | Fully Qualified Domain Name | IP Address
External | N/A | 172.16.0.9/29
Reverse Proxy | ocscontent.contoso.com | 172.16.0.10/29
Perimeter | N/A | 172.16.0.1/29
Internal | N/A | 192.168.0.100/24

You will also need to create unique subnets for your public IP address space. ISA Server will need two IP addresses on its external interface (one of which will be used for the reverse proxy), and you will need four public IP addresses for your perimeter network (three for the Access Edge Servers and one for the ISA Server perimeter interface). As an example, this is shown in Figure 3 as 29-bit subnet mask (255.255.255.248), which would give you six usable IP addresses per subnet.
If you have been allocated only a small number of public IP addresses, you can use network address translation for the Access Edge Server and the Web Conferencing Edge Server roles and connect the A/V Edge Server directly to the Internet. However, this approach is a little less secure in that you are bypassing the packet inspection capabilities of ISA Server and would require a third network interface card for your Edge Server.

Configuring ISA Server 2006
To configure the 3-Leg Perimeter, you need to launch the ISA Server management console and select Networks under the Configuration node in the left-hand pane, as shown in Figure 5. Next, click on the Templates tab in the right-hand pane and select the 3-Leg Perimeter template to start the Network Template Wizard.
This process will erase any existing configuration and rules, so note that if you are not using a new system, you should take care to export the configuration, an option offered by the wizard on the second screen. Clicking Next on the second screen begins the configuration process by asking you to input the IP address ranges that define your internal network.
Figure 5 Selecting 3-Leg Perimeter template
You have a number of options to help define the internal address space. If your organization is small, simply adding the network adapter that is connected to the corporate network is sufficient. Larger organizations will need to use the other options, such as adding IP address ranges to fully define their internal address space.
After entering this information, click Next to move to the next screen to define the perimeter network address space. It is usually sufficient to add the adapter you have dedicated to the perimeter network. Next, you must select a firewall policy. Be sure to choose the "Allow Unrestricted Access" firewall policy, then click Next to go to the Summary screen where you can review your configuration. Select Finish to complete the wizard and then, to accept these changes, click Apply and then OK.
The basic 3-Leg Perimeter is functional at this point but it needs some additional configuration in order to permit network traffic between the OCS Edge Servers and external users. The first thing to note is that the default configuration of a 3-Leg Perimeter in ISA Server includes support for VPN users. If you don't need this type of remote access, remove this item.
To do so, select Firewall Policy in the left-hand pane of the ISA Management console and then right-click the rule called VPN Clients to Internal Network and select Delete. To accept the changes, choose Apply and then OK. Two rules remain: the Unrestricted Internet access rule and the Default rule.
The next step is to add the computer objects that represent your Edge Servers. Select Firewall Policy and then choose the Toolbox tab, as shown in Figure 6.
Figure 6 Firewall Policy rules
Click on the New button and select Computer from the dropdown menu. Add the name of the Edge Server, for example Access Edge, and then enter the IP address for that server. Repeat this step for the A/V Edge Server and the Web Conferencing Edge Server. When you are finished, you should see your three computer objects listed under the Computers container.
The next step is to add the protocols used by OCS to the ISA Server configuration. You will need to add two new protocols, as shown in Figure 7.
Figure 7 Protocols used by OCS
Protocol Name | Protocol Type | Protocol Direction | Port Range
Mutual Transport Layer Security (MTLS)/Session Initiation Protocol (SIP) | TCP | Outbound | 5061-5061
Simple Traversal of UDP through NAT (STUN) | TCP | Outbound | 50,000-59,999
 | UDP | Send | *50,000-59,999
 | UDP | Send | 3478-3478

Note the asterisk in Figure 7. In OCS 2007 R2, this port requirement is necessary only if you use the A/V capabilities of OCS with a Federated Partner running Office Communications Server 2007. Remote users will not need these ports to be open.
It is worth emphasizing that it is a security best practice to only open ports that you require. For example, consider A/V conferencing with a Federated Partner, which requires UDP ports in the range 50,000–59,999. If you don't have a Federated Partner then you don't need to open these ports.
In the ISA Server management console, within the Firewall Policy and the Toolbox tab selected, click on Protocols, then on New and on Protocol to launch the New Protocol Definition Wizard. When the wizard launches, enter a name for the protocol, then click Next to go to the Primary Connection Information screen. On this screen click New and then add the information for the MTLS/SIP protocol, as shown in Figure 7.
To finish adding the protocol, click OK and then the Next button twice; you do not need to configure anything on the Secondary connections screen. Now click the Finish button on the Summary screen, and repeat these steps for the STUN protocol. Make sure you apply these changes to ISA Server when you have finished adding the protocols.
The Persistent Shared Object Model (PSOM) protocol (a proprietary protocol for transporting Web conferencing content) is not listed in Figure 7. This is because PSOM is used for traffic between the Web Conferencing Server and the Web Conferencing Edge Server. This traffic is sent out on the internal network card of the Edge Server.
After adding the above two protocols from Figure 7, the next step is to create the three Access rules that will permit users to connect to the Edge Server from the Internet. Once again, having this information at hand will make these configuration steps a lot simpler and less prone to error. Figure 8 shows the information you will need to create the three external access rules.
Figure 8 Access rule configuration
Access Rule Name | Rule Action | Protocols | Access Rule Source | Access Rule Destination | User Sets
Access Edge | Allow | HTTPS MTLS/SIP | External | Access Edge | All Users
A/V Edge | Allow | HTTPS STUN | External | A/V Edge | All Users
Web Conferencing Edge | Allow | HTTPS | External | Web Conferencing Edge | All Users

Start by selecting Firewall Policy and the Tasks tab in the ISA Server Management console and then click on Create Access Rule to launch the New Access Rule wizard. You can create the rules in any order, so let's start with the Access Edge rule. Once the wizard launches, enter a name for the rule and click Next. On the Rule Action screen, make sure that the Allow radio button is selected and click Next.
The following screen requires you to add the Protocols to which the rule applies. Click the Add button on the right-hand side of the screen to launch the Add Protocols window. Under the Common Protocols folder, select HTTPS and press Add, then select the STUN protocol—which should be listed under the User-Defined folder—and click Add. Click Close and then Next to move onto the Access Rule Sources screen.
This step requires you to select the Access Rule source, and in the case of the Access Edge rule, you will need to select the External network object by clicking Add and selecting it from the Networks folder. Then click Close and then Next to move to the Access Rule Destination screen. On this screen click Add and select the Access Edge computer object you created earlier from the Computers folder. Click the Close button and then Next to move to the User Sets screen.
Leave the All Users set default selection and click Next. Review the Summary, then click Finish to complete the process. You can now create the two remaining access rules using the information you compiled based on Figure 8. Make sure you apply these changes to ISA Server once you have finished.

A Word about Certificates
The last steps in this configuration process are focused on creating the SSL listener and creating the reverse proxy (publishing a Web application) for Office Communications Server. It's important to understand the certificate requirements of Office Communications Server and how these requirements impact ISA Server configuration.
The most important point to note here is that Office Communications Server requires the use of x.509 certificates and does not support wildcard certificates in the Common Name (Subject Name). You will need to specify a Subject Alternate Name (SAN) when requesting the certificate for the Edge Servers.
Since ISA Server 2006 SP1 introduced full support for SAN certificates, this will not present any problems. With this in mind, you need to address the certificate requirements for both the internal and external interfaces of the Edge Server. If your Active Directory environment does not use a top-level domain namespace, you will need to use a certificate from a trusted third-party Certificate Authority (CA) for the external interface and a certificate from an internal enterprise CA for the internal interfaces. In this scenario, the Root Certificate for your enterprise CA must be installed on clients that will access OCS internally as well as on the ISA Server; this ensures that the necessary trust relationships are in place for the OCS configuration. The external third-party certificate should already be trusted, and therefore the Root Certificate of the third-party CA doesn't need to be installed on all clients.
The certificate required for the reverse proxy configuration corresponds to the FQDN of the OCS address book and conference content download. In Figure 4, this was ocscontent.contoso.com but can obviously be anything you choose as long as the certificate comes from a trusted third party. Of course, your SAN certificate from this third party would also include the FQDNs of your Edge Servers, samples of which you can also see in Figure 3.

Reverse Proxy
The first step in creating a reverse proxy for OCS is to create an SSL Web Listener. To do this, click on the Firewall container in the left-hand pane and select the Toolbox tab in the right–hand pane. Select Network Object from the list, click the New button and select Web Listener from the dropdown menu. This will launch the New Web Listener wizard, which prompts you to enter a name for the Web Listener.
The name should be meaningful to you, but it doesn't necessarily have to be associated with OCS as the Web Listener could potentially have multiple uses. When you click Next, the Client Connection Security screen appears with the default option selected—Require SSL secured connections with clients. Leave the selection as is and click Next to move to the Web Listener IP Address screen, where you should check the External networks option. Next, click the Select IP Addresses button and choose the IP address that you have assigned to the reverse proxy (see Figure 4).
After clicking OK and then Next, you will see the Listener SSL Certificates screen. Select the option to Assign a certificate for each IP address and then click the Select Certificate button. Now select the certificate associated with the OCS address book and Web conference content that was discussed earlier. After selecting the certificate, click the Next button to configure Authentication Settings. Make sure that No Authentication is selected in the dropdown box and then click the Next button twice. Finally review the Summary screen and click the Finish button to complete the creation of the Web Listener.
Once the Web Listener is created, you can create the Web Site Publishing rule. To do this, click on the Firewall container and select the Tasks tab, then click on Publish Web Sites to launch the New Web Publishing Rule Wizard. The first piece of information to enter is the name of the rule, so enter a meaningful name such as OCS Content and click Next. On the Select Rule Action screen, select Allow and click Next to move to the Publishing Type screen where you will select Publish a single Web site or load balancer and then click Next.
To configure Server Connection Security, select the option to use SSL, then press Next to proceed to the Internal Publishing Details screen. Here you need to enter the internal name of the Web components server. Click Next and enter the path information, which should be /* to allow all paths. Click Next and enter the public name you created for the Address Book and Web Conference content downloads (in the example here it is ocscontent.contoso.com). Leave the other selections at the defaults and click Next.
Now select the Web Listener you created and click Next. On the Authentication Delegation screen, the dropdown box should read No delegation, but client may authenticate directly. Click Next and confirm that All Users is selected on the User Sets screen, then click Next again and then Finish to complete the process. The configuration of ISA Server is now complete.

Last Words
Extending Office Communications Server to support remote users and partners can yield tremendous benefits but requires a great deal of planning, particularly when it comes to securing your Edge Servers. ISA Server 2006 provides a robust, flexible, and scalable solution that is the ideal platform for securing Office Communications Server 2007.

Alan Maddison is a Senior Consultant specializing in Microsoft technologies with Strategic Business Systems, a division of Brocade.


Office Communications Server
Managing OCS 2007 R2 from the Command Line
Greg Stemp and Jean Ross
At a Glance:
  • Configuring OCS 2007 R2 with LCSCmd.exe
  • Prepping Active Directory for Office Communications Server
  • Creating the Enterprise pool and activating server roles
  • PWorking with certificates

There's a spider under the sofa. It peeked out a moment ago, then went back. It's a very large spider, at least in the eyes of one of us. We're going to pretend it's not there, and maybe it will stay put. Let's do something to take our minds off of it. The more confusing and complicated that something is, the better.
OfficePalooza

All right everyone, it's time to have some fun. Get your head out of all the user manuals. Stop worrying about how to get that pivot table exactly right. Forget about trying to format your Microsoft Word document just so. It's time to enjoy yourself and—maybe—learn just a little bit. Join us in April for OfficePalooza.
OfficePalooza is an online extravaganza you won't want to miss. Are you an expert in VBA? Maybe you're not an expert but you just want to give it a try. Maybe you've thought about it but haven't had the time to try it. Or it could be you just aren't sure it's your thing. Well guess what? It doesn't matter which category (if any) you fit into. If you want to have some fun playing with Microsoft Office (and maybe win a prize), OfficePalooza is for you.
OfficePalooza is the event of the year. There will be all sorts of games you can enter where prizes will be awarded. You'll also find all new articles and information on customizing your Microsoft Office apps. The event kicks off in April. Be sure to pick up your copy of TechNet Magazine (or read it online) to get started. Then go to the OfficePalooza Web site—and join in on all the fun.
Did we mention prizes? Well, in case you didn't hear, there will be prizes. Don't miss out!
OfficePalooza is being brought to you by the Microsoft Office Developer User Assistance team, TechNet Magazine, and Former Scripting Guys Greg Stemp and Jean Ross.
And what's more confusing and complicated than installing and configuring Microsoft Office Communications Server (OCS) 2007 R2? OK, we probably shouldn't have said that. To clarify, OCS 2007 R2 is a little complicated, but that's the nature of a product that encompasses so much.
On the bright side, it comes with a very nice setup wizard that walks you through all of the steps of installation and configuration. And on the brighter side, OCS 2007 R2 also comes equipped with a command-line utility named LCSCmd.exe that allows you to install and configure the product without the use of a wizard.
The spider is peeking out from under the sofa again. We'll continue to ignore it long enough to answer the question you're probably thinking: what's so bright about using a command-line utility rather than a wizard? We wondered that, too, so we asked the people we work with who seem to have some idea of what they're doing.
The answer has to do with deploying software within an enterprise. Command-line utilities, such as LCSCmd, can help to automate processes and allow for quick recovery of an application if there is a hardware failure. This made a certain amount of sense to us, so we decided that we should introduce you to LCSCmd.
So here we go. (And there goes the spider. No. Wait. It's back under the sofa again.) As we just mentioned, LCSCmd is a tool that allows you to set up and configure OCS from the command line. It accepts parameters that tell it what you want to do.
We're not going to go over them all here; there's a command-line reference nearly 100 pages long that details that. We're just going to show you a few key commands and explain what they do. In addition, we'll show you some of the commands and parameters that are new in Office Communications Server 2007 R2.
OCS works closely with Active Directory. Before OCS can even be installed, Active Directory has to be ready for it. (Keep in mind that most of this can be done from the setup wizards, but we're showing you the command-line version anyway.)
To get Active Directory ready, you need to prep the schema, forest, and domain. Prepping Active Directory means we're adding attributes that OCS requires, things such as whether someone is enabled in the system to use OCS, whether a person's communications should be archived, and the version information of the server. To prep the schema, type this at the command line:
LCSCmd /Forest /Action:SchemaPrep
Does it get any easier than that? Actually, it does. These commands are not case sensitive, so we could have entered it like this:
lcscmd /forest /action:schemaprep
To prep the forest and domain, do the exact same thing, except use an action of ForestPrep for the forest, and for the domain use /Domain rather than /Forest with an action of DomainPrep. You know, like this:
lcscmd /forest /action:forestprep
lcscmd /domain /action:domainprep
Those three simple steps will get Active Directory all ready to go. Keep in mind that most of the commands in this article have more parameters than we're showing you here. There are far too many optional parameters to explain in this article, so you'll have to look at that 100-page document to get all the information. Or you can check the command-line syntax help, like this:
lcscmd /forest /action:schemaprep /?
You simply type the action you want to know more about followed by /? to get a list of all the possible parameters for that particular action.
Speaking of help, how did that spider get across the room? We hope there's not more than one. There it goes into the bookshelf.
Every time you run a command using LCSCmd, a log file is created. A log file will look something like the file shown in Figure 1. Unless you specify a name and location for this file by using the /L parameter (followed by, of course, the name and location of the log file), the log file will be saved to the %temp% folder. The name of the file will be a mixture of the command and the date. For example, run this command:
LCSCmd.exe /Forest /Action:CheckSchemaPrepState
Figure 1 Log file created by LCSCmd
If you ran this command on December 19, 2008, at 12:42 a.m., your log file will be here:
%temp%\Forest_CheckSchemaPrepState[2008_12_19]
[00_42_00].html
If you want to check a log and you don't remember exactly what time it was, just look in the %temp% folder and you can probably figure it out. Plus LCSCmd helps out by displaying the name of the log file as part of its output to the command window (see Figure 2).
Figure 2 Command window output
In case you're wondering what that previous command does, (you know, the one where the CheckSchemaPrepState action is run against the Forest), it checks the schema prep state of the forest. OK, that one was a little bit obvious. But what exactly does it mean to check the schema prep state? It is simply the process that makes sure that everything in the schema is ready for an installation of OCS.
After you run LCSCmd to do a SchemaPrep, it's not a bad idea to follow that with a CheckSchemaPrepState run just to make sure all went well and to get a detailed report of the state of the schema. You can do the same thing for ForestPrep and DomainPrep; simply use the actions CheckForestPrepState and CheckDomainPrepState, respectively. Like this:
LCSCmd.exe /Forest /Action:CheckForestPrepState
LCSCmd.exe /Domain /Action:CheckDomainPrepState
Remember earlier in the article where we said those three lines were all you needed in order to get Active Directory ready? Well, that's not entirely true. There's one more thing you need to do before Active Directory is ready for OCS.
If you're installing Enterprise Edition, you need to create an Enterprise pool. Enterprise Edition requires several servers, including one or more front-end servers and a back-end database server, plus (in most cases) a hardware load balancer. A pool is how these servers are grouped together.
The command for creating a pool is a little more complicated than the commands we've seen so far. Take a look:
LCSCmd /Forest /Action:CreatePool /PoolName:Pool01
 /PoolBE:Pool01-BE\Live /RefDomain:contoso.com
 /MeetingContentPath:\\OCSShares\MeetingContent
 /MeetingMetaPath:\\OCSShares\MeetingMetaData
 /AppDataLocation:\\OCSShares\AppData
/ClientUpdateLocation:\\OCSShares\ClientUpdate
This action takes place on the Active Directory forest, so you start by specifying the Forest parameter. (Don't spiders belong in the forest? They definitely don't belong in a bookshelf.) Next comes the action to create a pool, which is CreatePool. After that you enter the PoolName using whatever name you want for your pool.
Every pool needs a back-end database. (OCS uses this database in order to store user information.) When we create the pool, we use the PoolBE parameter to tell the pool which database that is and where it is. Finally, we need to put in some paths that will tell the pool where presentation content, meeting metadata, application data, and client update information is going to be stored. (To find out what all of those things are, you will actually have to go in and read the official documentation and get to know the product a little. Hey, we can't cover everything in this one article.)
OCS comes with a lot of different server roles, such as the Application Host, Mediation server, Archiving server, and Web Components server. A server role doesn't start working simply because you install it; you also need to activate it. And this just happens to be something else you can do from the command line by using LCSCmd.
Here's an example of a command that activates the Application Host:
LCSCmd /AppServer /Action:Activate /PoolName:Pool01
 /Password:p@ssw0rd
All we did was specify the server role, in this case AppServer for Application Host, and follow that with the action Activate. For an Enterprise installation, we include the pool name and password. Activating other server roles is done in a similar way, as they all use the Activate action.
In case you were wondering (you probably weren't, but just in case), using AppServer as our example wasn't a random choice. We used that one because AppServer and all its actions are new in Office Communications Server 2007 R2.
One of the other actions you are able to perform on AppServer from LCSCmd is ActivateApp. It will activate whichever of the four applications—Conferencing Attendant, Conference Announcement Service, Outside Voice Control, and Response Group Service—you want to use.
Here's an example of a command to activate Outside Voice Control:
LCSCmd /AppServer /Action:ActivateApp
 /ApplicationID:Microsoft.Rtc.Applications.Ccs
 /Password:P@ssw0rd
Notice we start by specifying AppServer, then we put in the action, ActivateApp. Next, we need the application ID. For Outside Voice Control the application ID is Microsoft.Rtc.Applications.Ccs. (See Figure 3 for a list of application IDs for all four applications.) Last but not least we enter our password and, presto, Outside Voice Control is now activated.
Figure 3 Application IDs
Application Name | Application ID
Conferencing Attendant | Microsoft.Rtc.Applications.Caa
Conference Announcement Service | Microsoft.Rtc.Applications.Cas
Outside Voice Control | Microsoft.Rtc.Applications.Css
Response Group Service | Microsoft.Rtc.Applications.Acd

We want to note that we're assuming you already know what some of these applications are. In case you don't and you're reading this article just to keep track of the spider, we'll tell you that Outside Voice Control connects mobile users to OCS. (We think the spider is still in the bookshelf, somewhere between Adventures of Huckleberry Finn and The Adventures of Tom Sawyer.)
As you might expect, a product that has to do with communications needs to have a lot of security built into it. Part of that security in OCS is the use of certificates. As you might have noticed, in this article we're not talking much about how and why you do things; there are thousands of pages of help documentation and a resource kit to do all of that. So we're not going to explain how certificates work in OCS—where you use them, why you use them, and so on. What we are going to do is show you how to use LCSCmd to work with certificates.
In OCS 2007, you could use LCSCmd to request a certificate as well as to import and export certificates. You can still do those things in OCS 2007 R2, but R2 adds the ability to assign a certificate to a server. You can either assign the certificate after you have requested or imported it, or you can assign it at the same time you request or import it. Here's an example of requesting a certificate and assigning it to the current server, all in the same command:
LCSCmd /Cert /Action:Request /OU:Marketing
/Org:contoso /sn:Pool01.contoso.com
/country:US /city:Redmond
/state:Washington /assign:True
/ca:dc.contoso.com\contoso-CA
All commands pertaining to certificates begin with the Cert parameter. Here we're requesting a new certificate, so we've used the Request action. Next we need to specify the organization unit (OU) and organization (Org) to which this certificate will belong.
The next parameter, sn, is the subject name of the certificate. The subject name is the fully qualified domain name (FQDN) of the current server or pool, and in this example we've used the FQDN of the pool. For server roles that are on servers other than the front-end server, the FQDN of the server must be entered as the sn parameter value.
Now we put in our country, city, and state. The next parameter is the one that's new in OCS 2007 R2: Assign. Set the Assign parameter to True to immediately assign the certificate to the server or pool. Finally, we enter the name of the certification authority.
To assign a certificate that already exists, use the new Assign action, like this:
LCSCmd /Cert /Action:Assign /issuer:contoso.com
 /subjectName:Pool01-Certificate /Components:AP,MR
We're once again using the Cert parameter to let LCSCmd know we're working with certificates, and we're using an action of Assign to assign the certificate. Because the certificate already exists, we need to specify the Issuer (this is the common name of the certificate issuer), then we tell LCSCmd which certificate it is we're assigning by supplying the SubjectName of the certificate.
We have also included the optional Components parameter in our example. It's required if you're assigning the certificate to an Access Edge server (AP), a Web Conferencing Edge server (DP), or an A/V Edge server (MR). Here we're assigning it to the Access Edge server and the A/V Edge server.
Anybody know if there's some kind of security that will keep spiders out of your house? This spider now seems to have an interest in The Hitchhiker's Guide to the Galaxy.
There are a few more new parameters that have been added to OCS 2007 R2, but there's one in particular that just might come in handy from time to time: Broadcast Message. A broadcast message in OCS is an alert that is sent by the administrator to all users (technically they're called Session Initiation Protocol, or SIP,-enabled users) or users hosted on a specified pool.
Here's an example of a broadcast message:
LCSCmd /server /action:BroadcastMessage /Role:Proxy
/Message:"The system is going down for maintenance
at 7:00 PM PST."
This action is related to a particular OCS server role, so we've used the Server parameter. The action is, logically enough, BroadcastMessage. Next, we specify which server role we are working with. In this instance we've specified the Proxy server role, but we could also have specified Standard Edition server (SE), Enterprise Edition server (EE), Workgroup Proxy server (WorkGroupProxy), or Edge server (AP).
Finally, we include the message. And that's it. Uh-oh, that's not it for the spider—it looks like it's coming this way.
Keep in mind that this message isn't necessarily designed for immediate notifications, such as "The system is going down for maintenance in five minutes," simply because in a very large pool it can take some time to get the message to everyone. For example, in a pool with 50,000 users signed in, the message can take almost half an hour to get out to everyone. Needless to say, the message that the system is going down in five minutes won't be very useful half an hour later.
Just one more note about using LCSCmd. You can run the command remotely. Simply follow the first parameter with the FQDN name of the server you're working with. For example, if you're working remotely against a forest, your command would begin like this:
LCSCmd /Forest:contoso.com …
That's about it for our introduction to LCSCmd. That's about it for our spider, too. We'd like to say that no spiders were harmed in the writing of this article, but unfortunately we can't. Sorry about that.

Against all odds, Greg Stemp and Jean Ross work for Microsoft.


Office Communications Server
A Powerful Tool for OCS Planning and Deployment
Stephanie Pierce
At a Glance:
  • Specifying OCS 2007 R2 options
  • Planning configuration options
  • Working with topologies
  • Exporting the results

Contents
Selecting OCS R2 Options
Configuring the Primary Datacenter
Configuring the Remote Site
Working with Topologies
Working with the Results
To help facilitate planning a deployment of Office Communications Server (OCS) 2007 R2, Microsoft has developed a Planning Tool. This tool, which is a Windows Presentation Foundation (WPF) application, walks you through a series of questions gathering information about the features your organization requires, the number of unified communications users you have, and how you anticipate these users will utilize the supported features.
Using the information you provide, the Planning Tool does a number of things. It creates a recommended topology for each of your central sites (a site where OCS 2007 R2 is hosted locally), determines the hardware you will need, customizes the steps for planning your deployment, and customizes the steps you must take to deploy OCS 2007 R2.
You can save the topology and consult it later in the tool, and you can even export your topology to Microsoft Office Visio 2007 where you can make your own changes if necessary. You can also export the list of hardware and configurations for all of your sites to Microsoft Office Excel 2007.

Selecting OCS R2 Options
Before you run the Planning Tool, make sure you have the Microsoft .NET Framework 3.5 SP1 installed. Once that is set, you can download the Planning Tool. In order to run the tool's executable on Windows XP, click Start, point to All Programs, point to Microsoft Office Communications Server 2007 R2, and then click Planning Tool. If you are using Windows Vista and Windows Server systems, click the Start button, point to All Programs, click Microsoft Office Communications Server 2007 R2, and then click Planning Tool.
For this example, I will use a fictitious company called Litware Inc. that is planning to deploy OCS 2007 R2 at two sites: its New York office and its Dublin office. The New York office is the Litware primary datacenter, and Dublin is a small remote site.
The team at Litware installs and runs the tool. Since team members are not familiar with the features of OCS 2007 R2, they decide to click Get Started on the Welcome page so that the tool will walk them through all of the notable new features. If it happened to be that the Litware team was already familiar with the features, team members could skip this step and go ahead to design each of their sites by clicking Design Sites. This would allow them to check which features they want for each site.
As the team steps through the wizard, it's presented with the following options:
Audio and Video Conferencing Users can participate in audio and video conferences using the Office Communicator or Office Live Meeting client.
Web Conferencing Users that are both inside and outside the firewall can create and join Web conferences that are hosted on internal servers.
Communicator Web Access Users are able to access the instant messaging, presence, and conferencing features of OCS 2007 R2 using a supported Web browser and without connecting through a Virtual Private Network (VPN).
Enterprise Voice Users can choose the most appropriate way to communicate with colleagues throughout the enterprise when Enterprise Voice is deployed along with instant messaging and conferencing and is fully integrated with Microsoft Outlook. Users can place calls from their computers and Office Communicator Phone Edition.
Monitoring Call-detail records relating to unified communications sessions, as well as quality metrics, are captured at the end of each audio and video session. Monitoring also provides usage statistics, trends, and visibility into media quality.
Archiving Instant messaging conversations are archived for compliance reasons.
Unified Communications Applications This option provides a platform on which you can deploy, host, and manage unified communications applications. Four applications are available: Response Group Service (which automatically answers and distributes calls to an available help desk agent), Conferencing Attendant (which enables callers from the public switched telephone network, or PSTN, to join and connect to an Office Communicator conference), Conference Announcement Service (which plays announcements in conferences, such as the name of a person joining), and Outside Voice Control (which provides Enterprise Voice functionality and call control to mobile phones and other devices).
Group Chat Users can communicate using persistent group chat. Unlike multi-party instant messaging, the conversations in Group Chat are persisted so that they can be accessed at a later time. Conversations are also secured so that only members of the specific chat can access the persistent conversation and resources.
Device Update Service The process of updating all of the unified communications devices, such as Microsoft Communicator Phone Edition and Microsoft RoundTable, is automated.
Federation Users can establish communication between other external organizations. Users can initiate instant messaging sessions, exchange notifications, and subscribe to each other's "presence."
Public Instant Messenger Connectivity Users can establish communication with public providers, such as MSN, Yahoo!, and AOL. A separate license is required in order to do this, though.
High Availability Standby servers help to minimize downtime.
The team is interested in deploying all of these features except for the Communicator Web Access option.

Configuring the Primary Datacenter
After the team has completed filling out the wizard, team members can then enter the Site Name (New York), Domain Name (litwareinc.com), and Number of Users (60,000) on the Central Sites page, which is shown in Figure 1.
Figure 1 Central Sites page for New York
After the team has finished filling out the Central Sites page and clicks Next, the Enterprise Voice settings page is presented. Team members want to pilot 20% of their unified communications users for Enterprise Voice and, they anticipate their users will make approximately two calls per hour, which is considered to be typical medium traffic. Lighter traffic would be approximately one call per hour, and heavier traffic would be three or more calls per hour.
Since Litware uses a T1 network line, the team selects T1. And since the organization does not have an IP-PBX that is compatible with OCS, members leave this option unchecked.
The team plans to deploy gateways in various sizes, so its members select the Variety of gateways option. They select "2 processors, quad-core, 2.66GHz" for their Mediation server deployment. Once they have filled in their phone settings, the page looks like the screen shown in Figure 2.
Figure 2 Enterprise Voice settings
The team clicks Next and is presented with a capacity planning for Group Chat. Members choose 6% (the default setting) for the number of users that will be using Group Chat at one time.
The Planning Tool now asks for information about external user access and whether high availability is required for external users. The team chooses the first option, which is "Yes, and I want to deploy edge servers in my perimeter network." Members also check the option "Enable high availability for my external users."

Configuring the Remote Site
Since Litware has a remote site, the team clicks the Add Another Site option on the External User Access page. The team fills out the appropriate information on the Central Sites page, entering the Site Name (Dublin), Domain Name (litwareinc.com), and Number of Users (4,000). Since High Availability is not required for Dublin, the team unchecks this option.
The team proceeds to fill out the capacity settings. When they are presented with the External User Access page for Dublin, team members want to route all their external users through the New York site. Therefore, they select "Yes, but I want to use edge servers deployed at another site," and then they select New York, as shown in Figure 3. Since Litware does not have any more sites, they click Finish.
Figure 3 External User Access page for the remote site

Working with Topologies
The Planning Tool now presents the global topology for the organization, as shown in Figure 4. In the right-hand column, the Planning Tool indicates all the hardware the team will need for all its sites. If the team clicks on any of these sites, the tool will launch the default Web browser and display documentation and hardware requirement information. If the team clicks on the Ports, it is taken to the vendor site where members can see a list of compatible hardware that works with OCS 2007 R2.
Figure 4 Global topology page
If the team clicks on one of the sites, members are presented with a number of options:
Print Topology Prints the global topology along with the list of hardware.
Welcome Screen Navigates the user back to the Welcome Page.
Add Site Takes the user to the Central Sites page to add another site.
Save Topology Saves the topology in an XML file format.
Export to Excel Saves the topology in an Excel XML file format.
View Site Displays the topology for a site.
Edit Site Navigates to the Central Sites page where the user can modify features, site name, domain name, number of users, and any capacity settings for a site.
When the team double-clicks on the New York site, the topology shown in Figure 5 is displayed. The Planning Tool uses the OCS 2007 R2 User Model along with the number of unified communications users and the features enabled to create the topology and compute the hardware. Note that this topology is only a recommendation. If Litware uses a different user model than OCS 2007 R2, then the team may need to adjust the topology slightly or the number of servers needed.
Figure 5 New York topology
The OCS 2007 R2 User Model is available online. For instance, if the team at Litware wanted, it could choose to co-locate the Archiving server and Monitoring server in Dublin.
The team can access hardware and port requirements by pausing the mouse pointer over any of the components or by double-clicking on a component. The team can also view the port requirements for the firewall by clicking on the firewall icon.
The team sees a list of hardware required for this site in the right column, as well as a list of actions it can take:
Print Topology Prints the topology and hardware requirements.
View Planning Steps Navigates to a page that lists the customized planning steps for this topology, with each step linking to documentation located on TechNet Library.
View Deployment Steps Navigates to a page that lists the customized deployment steps for this topology, with each step linking to documentation located on TechNet Library.
View Global Topology Goes to the global topology page.
Welcome Screen Leads to the initial Welcome page.
Export to Visio Saves topology information to a Visio XML Drawing (.vdx) file format.
The team chooses to export the current topology to Visio. When team members open this .vdx file in Visio, they see the topology shown in Figure 6. Here they can add, delete, or move components.
Figure 6 Topology displayed in Microsoft Office Visio
Now the team has enough information to put together a reasonable recommended server count, location, and configuration of the topology. Figure 7 illustrates this configuration, with Active/Passive SQL Server clusters defined by (A/P) and hardware load balancers defined by (LB).
Dublin has one Standard Edition Server, since high availability is not required for this site. Notice that even though the team unchecked Communicator Web Access, there is still a Communicator Web Access server in the hardware list. This is because Litware is going to deploy the Conferencing Attendant and Conference Announcement Service options. At least one Communicator Web Access server is needed in order to configure the PIN numbers for dial-in conferencing for these features.
The planning team decides it's happy with the topology and server recommendations for both sites, so team members navigate back to the global topology. They click Save Topology so they can display this topology again in the Planning Tool and then click Export to Excel to save all of their site and hardware information.

Working with the Results
When opening the Excel XML file in Microsoft Office Excel 2007, the team is presented with a summary of all of its sites, usage profile information, and server profile information, as shown in Figure 8.
Figure 8 Planning Tool Summary in Excel
The Planning Tool Summary is divided into three sections:
Summary Displays the total number of sites in the organization.
Usage Profile Displays the total number of users in the organization, the number of users at each site, features enabled at each site, and capacity settings for each site.
Server Profile Displays the types and number of server roles required for each site, as well as the total server count for the entire organization.
The team clicks on the Hardware Profile tab and a list of the required hardware is displayed organized by hardware type, as shown in Figure 9.
Figure 9 Hardware Profile displayed in Excel
The Hardware Profile page is divided into two sections. The Summary displays each type of hardware needed based on hardware requirements across the organization. The Hardware Profile displays each hardware requirement, the necessary quantity, and the server role enabled on each for each site.
The Ports Requirements tab presents a list of ports that need to be enabled on each of the server components. The team at Litware is now set to move forward with planning its deployment for OCS 2007 R2 in New York and Dublin.

Stephanie Pierce is a Senior Tech Writer on the Microsoft Office Communications Server User Assistance team and a former Program Manager of the Unified Communications Group.


From the Editor The Speed of Innovation
Joshua Hoffman

Against the backdrop of all recorded history, one can't help but be amazed by the progress humanity has seen the last two centuries. From the light bulb to the automobile to the Internet, our world has witnessed revolutionary innovation at a pace remarkable relative to the past. There are thousands of examples from which to choose, but one of the most glaring demonstrations of this extraordinary achievement surely must be the telephone.
In barely more than 150 years, the telephone has gone from a twinkle in inventors' eyes to one of the most prolific and ubiquitous devices in the world. Zoom in even further to examine just the past decade, and we see the pace of development increase exponentially. Not only has it become a critical communications tool woven into the fabric of society, but it has grown even further to become something barely short of an artificial yet essential appendage. Push e-mail, integrated Web browsers, Bluetooth headsets—it is all practically commoditized in price and small enough to fit in the palm of your hand.
And the speed of innovation hasn't let up. We now see the underlying infrastructure of telephone communications changing, in a rapid move away from the traditional Public Switched Telephone Network and toward the use of the Internet as the underpinning for voice communications. The doors opened by Voice over IP (VoIP) technology are exciting and significant, to say the least.
This month we focus on the effects these changes will have in the business world by looking at the recent release of Office Communications Server (OCS) 2007 R2. We begin with an overview of what's new in this release, including major enhancements such as call delegation, team ring, group chat, as well as enhancements to presence, instant messaging, and conferencing. We'll also dig deeper into features like Remote Call Control, controlling OCS from the command line, securing OCS on the network, and more.
Also worth a mention this month (and I may be understating it a bit) is the public beta release of Windows 7, which has just occurred at the time of this writing. The beta has received overwhelmingly positive feedback so far, so hopefully you've had a chance to check it out. If not, go to microsoft.com/windows7 and give it a try. Needless to say, you'll be seeing a lot of coverage in our pages over the coming months, both of Windows 7 and Windows Server 2008 R2. If there are other particular topics you'd like to see us address, please drop us a line at tnmag@microsoft.com.
—Joshua Hoffman
Thanks to the following Microsoft technical experts: Pradipta Kumar Basu, Susan Bradley, Eric Charran, Rick Kingslan, Chermaine Li, Jingmei Li, Rui Maximo, Scott Schnoll, and Jim Truher.


Letters Readers Speak Out

Windows PE 2005
At my company we use LanDesk. I was told I need a licensed version of Windows PE 2005. Where can I get this? I have already downloaded the free version.
—Larry F.

The current version of Windows PE is available as part of the Windows Automated Installation Kit, which is available online. Versions prior to that were only available as part of a Microsoft Volume Licensing Agreement to Volume License holders.
—Joshua Hoffman, Editor-in-Chief, TechNet Magazine
From the TechNet Forums
TechNet Magazine is partnering with the Microsoft TechNet Forums, which hosts topics ranging from Windows Vista and Exchange Server to SharePoint, SQL Server, and general IT. Go to social.technet.microsoft.com/forums to see what people are talking about. Here are some examples of what you'll find there.

BizUnit and NUnit
QI am trying to build a testing framework using BizUnit and NUnit, and I need to be able to script the starting and stopping of a BizTalk application running on a 64-bit server. How is this done?
ATo start and stop the BizTalk applications, you could use the BTSControl command-line tool.
Another resource is Thomas Restrepo's Windows PowerShell script for starting and stopping the application hosts, a closely related task. It's available at "BTSReset with PowerShell." Take a look at his functions for starting and stopping the BizTalk hosts.
You can also have a look at the Microsoft SDC Tasks.
—Ben Cline, BizTalk Server General Forum

Mailbox Server Maintenance
QWhat are the best practices of managing mailbox server? I am looking for regular maintenance tips for using Exchange Server 2007 SP1 features and tips for doing it manually.
ATo manage messages inside mailboxes, you can create Managed/Custom folders and then configure Messaging Record Management (MRM). MRM is an important tool because it keeps messages that are needed to comply with company policy, government regulations, or legal needs, and removes content that has no legal or business value.
Various tasks to configure MRM to manage messages and e-mails of mailboxes include the following: Create managed folders, Create managed content settings, Create managed folder mailbox policies, Apply managed folder mailbox policies on mailboxes, and Schedule managed folder assistant on mailbox database.
Here are a few references you should also read: "Exchange 2007 Messaging Records Management, Part 1" and "Exchange 2007 Messaging Records Management, Part 2."
For more about Exchange, see these Exchange Server 2007 videos, hosted by CBT Nuggets trainer, J. Peter Bruzzese. Also, MSExchange.org has step-by-step articles with screenshots.
Finally, there is in-depth information on Exchange Server 2007 available on TechNet. And you can also read the interesting Microsoft Exchange Team Blog.
—Amit Tank, Exchange Server Forum

Got something to say? E-mail us at tnmag@microsoft.com, or visit our blog forum at blogs.technet.com/tnmag.


Toolbox New Products for IT Pros
Greg Steen

The opinions expressed in this column are solely those of the author and do not necessarily reflect the opinions of Microsoft. All prices were confirmed January 12, 2009, and are subject to change.

Tweak Your System
TuneUp Utilities 2009
tune-up.com/products/tuneup-utilities
As an IT professional, you most likely feel the desire to tweak and tune your machine to run as optimally as possible for your specific working style. What is probably of little or no concern to the standard user may be irritating to you, since you have a greater sense of what is going on under the covers.
One toolset that has been around for years, giving you an easy-to-use and reliable tuning, is TuneUp Software's TuneUp Utilities 2009.
The German company has had almost yearly upgrades to its TuneUp Utilities product since its first release in 1997. The latest version has a polished UI and is designed for Windows XP and Windows Vista (both 32- and 64-bit versions).
One cool part of the toolset is the Speed Optimizer, which performs a number of tests and asks you questions about your daily routine. It will then tweak and tune things such as your display settings, network stack, and so on to meet your particular needs.
The tool will also suggest to group and remove items from your startup, scheduling a task to check for application updates rather than having 907 different auto-updaters running in your task bar (this is only a slightly exaggerated number).
TuneUp Utilities also touts a one-click maintenance feature, which automates some of the toolset's tasks, removing temporary files, defragmenting hard disks, cleaning up the registry, and cleaning up your desktop on a scheduled basis without you having to intervene.
Beyond those automated features, the application lets you tweak individual items via its various tool UIs. The tools are split into six groups: Increase performance, Free up disk space, Clean up Windows, Solve problems, Customize Windows, and Additional tools.
Within the first group of tools, you can defragment your drives, compact and clean your registry, prune which applications run at machine startup, and launch the Speed Optimizer. One nice thing about the startup pruning capabilities is that you don't have to delete the items—you can just "switch" them off. The utility also conveniently groups the items into required, optional, and not needed so you can feel more confident about turning off less useful items.
The second group of tools, Free up disk space, lets you wipe temporary files and redundant backups as well as trim unneeded components from Windows. Or, you can use the Disk Space Explorer to see what types of files are eating up the space on your drives. This is a great way to find old ISOs and "hidden" MP3 collections on your machines.
In the Clean up Windows group, you can run or configure settings for the one-click maintenance feature, as well as search for and remove invalid shortcuts on your Desktop, Start menu, history lists, and quick launch bar. You can also see what is installed on your system and correct detected registry errors.
The Solve problems group provides tools that you can use to undelete files and folders, check for file system errors, fix physical disk errors, repair context menu items, restore standard desktop icons (such as the recycle bin), and add the display desktop icon back to the quick launch bar.
The fifth section, Customize Windows, lets you tweak the visual styles of Windows. You can, for example, configure icon sets, logon and boot screens, fonts, menu effects, and the general look of application and dialog windows. From within the UI, you can also browse free boot screens, icon sets, and other elements available from the TuneUp Web site and easily add them to your own list of available options.
Within this same group of tools, you can also turn off network resource scans, such as Universal Plug and Play (UPnP) and network shares, as well as stop automatic printer detection to speed up your computer's connect times.
The last group, Additional tools, gives you a direct registry editor, a graphical process manager, an uber-delete shredder (to obliterate files and folders), and a general hardware and software configuration system summary tool.
TuneUp Utilities is packed with tweaking tools, offering users a convenient and easy-to-access set of utilities. So if you want an easy toolset without sacrificing any features, take a look at TuneUp Utilities 2009.

Price: $49.95 (direct)
Tweak your system with TuneUp Utilities

Book Review
Configuration Manager 2007 Administrator’s Companion
microsoft.com/learning/en/us/books/9554.aspx
Maintaining slews of servers, desktops, laptops, and mobile devices across the enterprise is not an easy task. Getting machines up to date without interfering with corporate workflow is a bear, and undoubtedly the number of configurations you have to support expands with the size of the company.
To help ease deployment, configuration, and updates across the enterprise, Microsoft has System Center Configuration Manager (ConfigMgr) 2007, now in R2. You might want to take a look at Steven D. Kaczmarek's Microsoft System Center Configuration Manager 2007 Administrator's Companion (Microsoft Press, 2008) to get up to speed and fully understand all the bells and whistles (and, well, limitations) of ConfigMgr. Kaczmarek has worked closely with the System Center Configuration Manager team to give you the knowledge you need to use the product effectively.
The three main sections of the book tie nicely to the lifecycle of a ConfigMgr deployment: "Planning, Deploying, and Configuring," "Managing Clients," and "Site Database Management."
The book begins with an overview of the new and enhanced features of ConfigMgr 2007 as compared to previous versions, as well as an overview of the key components that comprise a ConfigMgr deployment. Then, following the old adage of "measure twice, cut once," the book discusses planning for an installation and getting the software installed in a test lab to familiarize yourself with all its options. Here you also learn useful tidbits such as the different ways in which you can deploy the client agents in your environment.
You can then read about configuring your installation, covering such topics as how to set up different distribution points for your package deployments. To help you learn how to utilize ConfigMgr 2007 in large environments, the book introduces multiple site structures and explains the parent-child nature of site hierarchies. Here you also learn about some of the performance, geographic, and Active Directory considerations for a site hierarchy. This part of the book ends with a look at the numerous analysis and troubleshooting tools available with ConfigMgr 2007, such as the status messages, queries, and the Configuration Manager Service Manager and System Monitor.
The second section of the book covers client management, beginning with more in-depth coverage of resource discovery and client installation. Within this section, you can see how to collect hardware and software inventory information into the central repository as well as how to generate asset reports. And you learn how to distribute software packages and how to create your own custom software packages from the ground up.
It seems today that every piece of software is updating almost every week and controlling those updates can be a burden. The book shows how you can deploy software updates in a controlled manner in your environment, ensuring only the necessary and required updates are installed based on the current state of your client machines. Of course, ConfigMgr isn't just limited to application installations and updates; the book also discusses how to deploy operating systems via an image in addition to the new system configuration management options available.
The third part of the book focuses on the central repository of a ConfigMgr 2007 installation. Here you learn how to query and generate reports from the data as well as create dashboards. There is also a good chapter on securing your environment, from network and account security controls to public key infrastructure (PKI) and certificates. Losing all that data would be tragic, and so the book ends with a couple of chapters on backup and recovery, showing you what maintenance tasks are involved in a ConfigMgr deployment as well as how to maintain the database through SQL Server management tools.
This, of course, only scratches the surface of what this book offers. ConfigMgr 2007 has many features and can really help you maintain control of your environment. But you'll need to know how to use it—and this book can help.

Price: $59.99 (list).

Fix Configuration Errors
HijackThis
trendsecure.com/portal/en-US/tools/security_tools/hijackthis
When things start to go awry on a machine, one of your first thoughts is probably "Oh, no—a virus." If you're confident in your user's antivirus software, the next thought is probably "Great, what phishing site have they visited now?" Or perhaps, "What program has he installed now that is messing up the system?" One tried-and-true utility that can help you diagnose a suspicious quirk on a machine is Trend Micro's free HijackThis tool.
HijackThis looks at common system settings, indicating those that may have been tampered with at some point since the system was installed. It reports on registry settings, host file entries, browser helper objects (BHOs), startup application lists, extra buttons within applications, scheduled tasks, services running on the machine, and more. Because the app doesn't give you an explicit indication of whether a modification is good or bad, you will likely want to keep this tool out of the hands of your general users. The TrendMicro Web site has a forum dedicated to HijackThis. There you can peruse or upload questionable finds from the program's search to gather information about the use and potential destructiveness of HijackThis.
The utility works on all desktop flavors of Windows from Windows 98 through Windows Vista. It's lightweight and requires no registry modifications, or installation. Download it with an installer as a simple zipped set of files or as an executable that runs directly on your machine.
Using HijackThis is simple. Launch the executable and select either "scan and save a logfile" or "scan only" to see what modifications it finds on the local system. You can back up current settings to ensure you can roll back changes should you make a mistake while trying to clean up a system.
If you use the application frequently or bring it around with you on your disk of troubleshooting utilities, you can also choose to add items to an ignore list so they won't occlude your view of potential issues, speeding up your analysis.
If you decide to "fix" an item, HijackThis will then either delete or restore the setting to default. In addition to that main functionality, HijackThis has a miscellaneous tools section with helpers, such as a simple process manager, a quick link to edit host files and the Add/Remove Programs panel, and an easy way to delete a file on reboot that can't be removed from memory. This is certainly a handy tool for IT pros, and the price can't be beat.

Price: Free.
Find and fix problems with HijackThis

Audit System Configurations
SysCompare Pro
mtmsoftware.com/syscompareproinfo.html
Knowing who's got what on which system without leaving your desk is an invaluable time-saver for a systems administrator (though I do recommend leaving your desk once in a while for your physical and mental health). The ability to compare a set of systems easily offers a great way for you to double-check installations and system configurations. This is also a good way to confirm the deployment of patches, group policy settings, and the like. One tool I find valuable for doing these sorts of tasks is SysCompare Pro from MTM Software.
After installing SysCompare, scan the target systems on your network by adding them individually by name with an IP address or by browsing Active Directory for the systems in which you are interested. Unfortunately, there is no way to import a list of computers from a file. But once you have added all your target machines, you can save the scans for reuse at a later time.
Once a scan is completed, the results are grouped into two categories: hardware and software. In terms of hardware, SysCompare scans general system information, such as BIOS type and version, system manufacturer and model, and hardware system type (such as x64). You can also view details about the processor, network adapter, logical and physical disks, and memory configuration. You can even retrieve information about all of the Plug-n-Play devices on the target system and what printers are currently set up on the machine. A particularly useful indicator will provide a list of any devices on the machine that are in a "problem" state. This could be due for example, to a bad driver or a hardware error.
The software category presents information about the operating system, including such details as which service packs have been applied, the current data execution-prevention settings, page-file settings, environment variables, shares, version and build numbers, and the current startup options. You can also see service and process details—such as the current state, the display name, and the real executable name— as well as the executing context. And the software category provides a quick listing of which applications run at startup and the current set of installed applications on the system—some useful information to have at you disposal when comparing systems and troubleshooting.
Within the UI, the results panes for the hardware and software details are presented in a familiar data-grid format, and you can group the information by column header. You can also export the data directly to Microsoft Office Excel for reporting and general reuse.
Aside from identifying individual machine components, one of the most useful features of this utility is the ability to compare differences between a set of systems. This allows you to see quickly, for example, which machines are out of date or have been configured with the wrong memory or have additional (unsupported) applications installed by the user.
If you are looking for a quick and simple tool for performing system audits and comparing configurations, you might want to take a look at SysCompare Pro. It isn't the cheapest utility, but you get a company-wide license and a lot of bang for your buck. A Lite version (very lite) is available for $99 and free licenses of the Pro version are available to qualified educational institutions.

Price: $1,499 (direct) to purchase a company-wide license.
Audit and compare systems with SysCompare Pro

Greg Steen is a technology professional, entrepreneur, and enthusiast. He is always on the hunt for new tools to help make operations, QA, and development easier for the IT professional.


Exchange Q & A Site Resiliency with SCR, Recommended Root Volume Size, and More
Henrik Walther

Q I'm currently architecting an Exchange Server 2007-based messaging infrastructure for a large enterprise requiring that the solution include site resiliency. So I'm considering deploying cluster continuous replication (CCR)-based Mailbox servers on Windows Server 2008 failover clusters with the active node in the primary (active) datacenter and the passive node in the secondary (backup) datacenter.
The datacenters are on different subnets but belong to the same Active Directory site, which means this is a supported scenario when installing the CCR-based Mailbox servers on Windows Server 2008. Would you recommend deploying CCR-based Mailbox servers in a multi-subnet environment?
A You're correct that this scenario is supported as long as you stretch the Active Directory site between the datacenters, as Exchange 2007 doesn't support deploying the active and passive CCR nodes in different Active Directory sites. Nevertheless, it's important to bear in mind that CCR was really designed for high availability within a datacenter, not for site resiliency (which is more about disaster recovery than high availability).
For this specific reason, the Exchange Product group introduced standby continuous replication (SCR) with Exchange 2007 SP1. SCR uses the same log-shipping and replay technology used by CCR, but SCR does not rely on Windows failover clustering functionality, as does CCR. This means that you can enable replication for both clustered and non-clustered Mailbox servers to an SCR target. That target can consist of a non-clustered Mailbox server or a standby cluster on which the passive Mailbox server role has been installed.
This is illustrated in Figure 1, which is part of the Standby Continuous Replication section in the Exchange 2007 documentation.
I don't recommend implementing a geographically dispersed cluster (geo-cluster) based on CCR, but it is, as already mentioned, fully supported by Microsoft. However, you need to be aware of the disadvantages of following this approach.
Figure 1 Standby continuous replication model
First, you must use a stretched Active Directory site. It seems that you already have this one settled, but it's worth mentioning for the rest of the readers out there who may not know this. Next, you should be aware that because the CCR nodes are located on different subnets, the clustered Mailbox server (CMS) will change its IP address during a failover to the other site. This change will need to be replicated to all DNS servers used by Microsoft Outlook clients and—just as important—all machines with Outlook clients connecting to the CMS must have their DNS cache flushed.
The Outlook clients will be disconnected from the respective mailboxes on the CMS during the period that this takes place. For this reason, you should change the DNS time-to-live (TTL) value for the CMS network name resource to five minutes (300 seconds) or less. For more on how this is done, refer to technet.microsoft.com/library/bb676687.aspx.
You must also take into consideration where you want to place the file share witness (FSW). The recommendation is to create the FSW on a Hub Transport server, but in which site? If you locate it on a Hub Transport server in the primary datacenter and the primary datacenter is lost, will an automatic failover happen? No, this is not possible if one of the CCR nodes and the FSW are down at the same time. On the other hand, it's likely that many would prefer the failover not to be automatic in a geo-CCR scenario. Be sure to read the guidance related to placement of the FSW in a geo-CCR scenario.
Finally, you should be aware that if a failover to the passive node in the backup datacenter occurs, any backfill from the Transport Dumpster on Hub Transport servers in the primary datacenter will not happen since these servers most likely are down. The net result is missing e-mail.
As you can see, there are many things to consider before you deploy a geo-CCR in your environment, far more than if you instead choose to use SCR for site resiliency.
Q Our organization consists of multiple physical sites spread across the U.S. as well as Europe, the Middle East, and Africa. Today all user mailboxes are hosted on Mailbox servers deployed locally at each physical site, but we want to consolidate those servers to one datacenter located in the U.S. Given this plan, can you tell us the maximum latency for Outlook 2003/2007 clients running in cached mode?
A It's good to hear all your clients are either Outlook 2003 or 2007 and run in cached mode, because cached mode is typically your lifesaver in consolidations such as the one you describe.
In the past, Microsoft recommended 1,000 ms or less end-to-end latency to the home Mailbox server for Outlook 2003 cached-mode clients. For non-cached-mode Outlook 2003 clients, the recommendation was 200 ms or less.
Based on my own personal experience, 1,000 ms is a little high even for Outlook 2007 cached-mode clients. When you get more than 500 ms, Outlook starts to hang and generally becomes sluggish. My recommendation is you should strive for latency less than 500 ms between the Outlook client and the home Mailbox server. In Figure 2, you can see the average response time for my Outlook 2007 client connected to a mailbox in Redmond.
Here's a tip: to open the Connection Status window shown in Figure 2, you can right-click the Outlook icon in the system tray while holding down the CTRL button. Alternatively, you can launch Outlook by clicking Start | Run and entering Outlook.exe /RPCDIAG.
Figure 2 Average response time in Outlook 2007
Considering that I'm located in Denmark, the average response times are acceptable. You can see the average response times from the global catalog server are drastically higher, but since these are used less frequently (for address book lookups and so forth), it doesn't matter that much.
Q We have just deployed Exchange 2007 SP1 in our organization. The Active Directory topology consists of two sites. In the first site, we have deployed a CCR-based Mailbox server and two servers each with the Hub Transport and Client Access server roles installed. In the second site, we have deployed a single copy cluster (SCC)-based Mailbox server and two servers with the Hub Transport and Client Access server roles just as in the first Active Directory site.
The majority of clients in each Active Directory site still run Outlook 2003, which means a public folder store is required for free/busy information and the offline address book (public folders will be used only for this purpose, not as a data repository). Our initial plan was to mount a public folder store on both the CCR- and the SCC-based Mailbox servers so public folder changes could be replicated between the Active Directory sites. But then we heard that Microsoft doesn't recommend having more than one public folder store in an Exchange organization if one is hosted on a CCR-based Mailbox server, because public folder replication and CCR replication don't behave well together.
So with all of this in mind, what would you recommend that we do? We don't want to go down a path not recommended by Microsoft. But at the same time, we don't want Outlook 2003 clients on each Active Directory site to contact the public folder store on the other Active Directory site.
A This is a very good question. You're correct that combining public folder replication and CCR replication for a public folder store should be avoided (details on why you should avoid it can be found in my January 2009 Exchange Queue & A column. Since you will use public folder functionality to enable legacy Outlook clients to perform free/busy lookups to download the offline address book (OAB), I recommend you install the Mailbox server role on one of the combined Hub Transport and Client Access servers in the Active Directory site where the CCR-based Mailbox server resides. Then move the public folder store from the CCR-based Mailbox server to this server.
Bear in mind, though, that for public folder replication to work properly, you must also have a mailbox database running on the server. Using the combined Hub Transport and Client Access server for free/busy lookups and the OAB will not put a big performance burden on the box, and it is what most Exchange architects do in such a scenario.
Q We are currently planning the storage layout for the Mailbox servers that will be part of the Exchange 2007 messaging environment we plan to transition to within the next six months. Since our enterprise consists of thousands of users, we plan to have 48 storage groups on each Mailbox server, all of which will be based on CCR technology.
Because of the number of storage groups, we will, of course, make use of mount points. Since we will create a mount point for each LUN on each of the CCR-based Mailbox servers, we are interested in hearing what the recommended minimum size is for the anchor drives where the mount points will be created.
A The Knowledge Base article "How to Configure Volume Mount Points on a Server Cluster in Windows Server 2008" describes how to configure volume mount points on a server cluster in Windows Server 2008. It states that if the root (host) volume—also known as the anchor LUN—is used extensively for mount points, it must be at least 5MB. But the recommendation for root volumes is different when it comes to Exchange.
In Exchange 2007, as well as previous versions of Exchange Server, it is a best practice to use a root volume between 100MBs and 500MBs. When running Exchange 2007 on Windows Server 2003-based servers, you can have problems creating a new database if the root volume has fewer than 20MBs of free space. See "Event 104 is logged after you create a new database in Exchange Server 2007" for more information about this specific issue.
Q Our organization's messaging infrastructure is based on Exchange 2007 SP1. All Exchange 2007 servers are located in the same datacenter and are based on CCR clustering technology, so we have local redundancy. But we have just set up a second datacenter to act as the backup in case our primary datacenter is lost during a disaster.
For Exchange, we want to deliver site resiliency by deploying one Hub Transport, one Client Access, and one Mailbox server in the backup datacenter. We then want to enable SCR from the CCR-based Mailbox servers in the primary datacenter to the Mailbox server in the backup datacenter. Before we start to build the Exchange 2007 servers in the backup datacenter, we have a question we hope you can answer. We want to know whether it's supported to enable SCR between SCR sources consisting of CCR-based Mailbox servers and an SCR target consisting of a standalone Mailbox server. And if this is the case, would you recommend that we follow this approach?
A The short answer is yes, this is fully supported. The long answer, however, is also yes, but you must remember that you can't recover the CMS located on the SCR source server(s) using the /RecoverCMS switch. You can only recover a CMS using the /RecoverCMS switch when the SCR target is a Windows Server 2003/2008 failover cluster on which only the passive Mailbox server role has been installed.
If you deploy a standalone Mailbox server as the SCR target, you'll have to recover the databases using database portability, a procedure that's more cumbersome than the RecoverCMS method. You can find the necessary step in the Exchange 2007 documentation in the article "Standby Continuous Replication: Database Portability." If you have Windows Server 2003/2008 Enterprise edition installed on the SCR target, you could also remove the Mailbox server role from it, form a failover cluster, install the passive Mailbox server role on one of the failover cluster nodes, and then recover your CMS using the RecoverCMS option.
If you have only one physical machine available right now but will have an extra machine (plus an additional license for Windows Server 2003/2008 Enterprise edition and Exchange Server 2007 Enterprise edition) in the near future, you could also start by forming a Windows Server 2003/2008 failover cluster consisting of a single node, and then install the passive Mailbox server role on this node. When you have that extra machine ready, you could install Windows Server 2003/2008 on it and configure the network settings and the like and then finally add it to the Windows failover cluster.

Henrik Walther is a Microsoft Certified Master: Exchange 2007 and Exchange MVP with more than 15 years of experience in the IT business. He works as a Technology Architect for Trifork Infrastructure Consulting (a Microsoft Gold partner based in Denmark) and as a Technical Writer for Biblioso Corporation (a U.S.-based company specializing in managed documentation and localization services).


Utility Spotlight VMC to Hyper-V Import Tool
Matthijs Ten Seldam

Code download available at: TenSeldamUtility2009_03.exe (815 KB)

Contents
VMC to Hyper-V Import Tool
The Scope of VMC2HV
Out of Scope
What about SCVMM?
What VMC2HV Does
Requirements
Future Version
With the release of Hyper-V in Windows Server 2008 and the recent release of Hyper-V Server 2008, people are starting to use Hyper-V for their test, development, and production environments. Creating virtual machines (VMs) with Hyper-V is very easy, and installing operating systems and applications in a virtual machine is as transparent as in the physical world. Many people, however, have existing VMs that were used with Virtual PC 2007 or Virtual Server 2005 R2 SP1.
Fortunately, these older VMs can be used with Hyper-V as well. But before that can occur, you must perform certain manual steps. At the very least, you need to attach the virtual hard disk (.vhd) files to the hard disk drives in Hyper-V. This requires creating a VM using the Hyper-V wizard, opening up the settings for the newly created VM, and then configuring the drives (probably IDE) with the virtual hard disk files.
Figure 1 VMC2HV lets you adjust almost any setting before creating the VM in Hyper-V
Within Hyper-V, you must uninstall the Virtual Machine Additions and install the Hyper-V Integration Services. When this is done, you have migrated the original VM to a Hyper-V VM.
But there are many other settings you may want from the original VM, such as those related to memory, CPU resource control, DVD image, floppy image, and SCSI controllers. Those settings are not stored in the VHD file but in the Virtual Machine Config (VMC) file.
If you want to include those settings in your new VM, you must open the VMC file in Notepad for reference and make the adjustments in Hyper-V accordingly—by hand. When you have several VMs, this process takes quite a bit of time.
The fact that Hyper-V lacks VMC import functionality drove me to develop a VMC to Hyper-V import tool. This tool imports the settings from a VMC file and displays all equivalent settings in its UI. From there, you can tweak the settings, update the virtual drive image paths, choose whether to create synthetic or legacy network adapters, and more. Once you are done, you can create the Hyper-V VM from the original VMC configuration with one click.

VMC to Hyper-V Import Tool
So what is the VMC to Hyper-V Import Tool, VMC2HV for short, and for what was it intended? As noted, VMC2HV imports the configuration from a VMC file so that you don't have to configure each Hyper-V VM manually. Both Virtual PC and Virtual Server use VMC files to store the hardware and other properties of a VM. VMC2HV reads the VMC file and maps all relevant properties to those for a Hyper-V VM. For those properties that did not exist in earlier VMs, VMC2HV provides additional options. Those properties that no longer exist are ignored.

The Scope of VMC2HV
The tool was initially developed simply to import Virtual Server VMC files. Virtual Server is a server product, and so is Hyper-V. But I received requests to add support for Virtual PC as well because many of the product-evaluation VMs are created with Virtual PC. So I did some additional testing with Virtual PC 2007 VMC files. The testing was not too extensive, but I did modify the code in several places to accommodate the differences between Virtual PC and Virtual Server.
I did not specifically test Virtual PC 2004 VMC files. I imported several and that worked, but I didn't actually test those VMC files since the product was superseded long ago. The same is essentially true for Virtual Server 2005 R2 SP1. I only tested VMC files under the latest release of Virtual Server 2005.

Out of Scope
The tool imports a VM configuration. This means it imports the hardware settings of the VM, but it does not modify the contents of the virtual hard disk(s). As noted, you must manually remove the Virtual Machine Additions and install the Integration Services. If you want automatic removal of Additions and installation of Integration Services, use System Center Virtual Machine Manager (SCVMM) 2008.

What about SCVMM?
VMC2HV was not developed to replace SCVMM functionality. SCVMM is the product you should use to import, create, and manage virtual machines in an enterprise environment.
SCVMM can import VMC files and provides additional management functionality. VMC2HV does the same but is intended for people who do not (yet) have SCVMM, such as those that are using Hyper-V on laptops or on only a couple of servers. Using SCVMM simply for importing VMC files is probably overkill.

What VMC2HV Does
So what does VMC2HV have to offer? The following is a summary of the tool's capabilities:
  • Import of both Virtual Server 2005 and Virtual PC 2007 VMC files
  • Creation of a VM on local Hyper-V host
  • Creation of a VM on remote Hyper-V host
  • Validation of virtual disk and ISO files in local scenario
  • Editing of virtual drive image paths (vhd, vfd, iso)
  • Swapping of the first SCSI disk with the first IDE disk
  • Specifying of static MAC addresses
  • Specification of either legacy (emulated) or enhanced network adapter
  • Specifying of the number of virtual processors and resource controls
  • Specification of management settings
  • Specification of COM ports
  • Specification of device boot order
  • Specification of alternate virtual machine path
  • Built-in help in a CHM file
  • Support for both x86 and x64 Windows Vista and Windows Server 2008
As you can see from the screenshot, VMC2HV not only imports the VM configuration, it also lets you adjust almost any setting before creating the VM in Hyper-V. Several shortcut keys have been included to help speed the process if all you want to do is import and create several VMC files.

Requirements
You can import VMC files from any file location, and you can then create the VM either locally or remotely. In the remote scenario, both the client where VMC2HV runs and the remote Hyper-V host must be in the same domain. Or alternatively, both client and remote Hyper-V host can exist in a workgroup, but you need to use mirrored administrator accounts (the same administrator using the same password). Other configurations simply do not work.
The tool prevents the importing of VMC files that contain either saved state information or Undo disks. VMs must be in Shut Down state, and Undo disks must be committed or discarded.
Chances are you're going to want to migrate your older VMs to Hyper-V, and if you don't yet have SCVMM, moving all the settings you need can be a chore. VMC2HV makes the process much easier.

Future Version
A new version of VMC2HV is under development, and it will incorporate several changes and improvements. Perhaps the most notable change is the use of a tabbed interface. This new interface was necessary to be able to provide more efficient access to additional properties that would otherwise require a larger window.
The new release will support all Hyper-V VM properties, including a number of new management properties such as Snapshot file location and Integration Services. Integration Services includes options for Operating system shut down and Time synchronization.
Networking will support the selection of already existing Hyper-V Virtual Networks, making it possible to attach network adapters to virtual networks prior to creating the VM. Finally, the new release will support Hyper-V v2, which is part of Windows Server 2008 R2.

Matthijs ten Seldam is Partner Technology Specialist at Microsoft for infrastructure products. He is focused in the areas of security, deployment, and automation. He is a subject-matter expert in the area of virtualization.


Utility Spotlight Screenrecorder
Burak Uysaler

Code download available at: UtilityOnlineMarch092009_03.exe (10,209 KB)

Whether you are having problems yourself getting something to work correctly on your computer and are working with tech support, or you're trying to solve such problems for your customers, friends, or your Mom, you have probably spent hours describing or explaining events over and over again in an effort to deal with the lack of clarity that exists when one party can't see what is going on. Now there's a solution. Screenrecorder is a very easy-to-use screen-to-video capture program, developed on top of Windows Media Encoder, that lets you easily capture what is going on to a small video file, which you can then send via e-mail to the appropriate person. That person can then watch the video just as if he is sitting next to you and you are showing him what's is happening on the screen.
Figure 1 You can choose to capture either the full screen or a particular window
Using Screenrecorder is very easy. When you first run the program, you will see a window like the one in Figure 1. You simply select either Full Screen or any program window from the drop down list, check the audio box if you want to record audio as well, and then click OK.
Next you'll see the screen shown in Figure 2. Just supply a filename for the video and then hit START to begin the capture. Screenrecorder starts to capture screen movements to the video file you specified. You can pause capturing at any time. When you click STOP, a PLAY button will be displayed at the bottom right. Just click and your captured video will be played by your default video player for .wmv files. That's about all there is to it!
Figure 2 After you specify a filename, press the Start button
So what is Screenrecorder good for? Just about any onscreen situation where visualization would help. You can record step-by step instructions to create training videos. You can capture problems as they happen to send to tech support. Instead of telling Grandma where she will find the photos on her machine, you can show her. Or she can show you what is happening if she gets an error when trying to run a particular program. With Screenrecorder, you don't need to read any help file—the program lets you know what to do from the beginning to your final video. Moreover, the tool is optimized for the best resolution and smallest-size video, so you never have to worry about any settings. There are no complex menus to wade through or to try to figure out what they're for. And Screenrecorder produces a .wmv file so it can be played on any Windows computer without the need for an audio/video decoder.
Screenrecorder simplifies screen capture for everyone.

Burak Uysaler began as a Support Engineer for Microsoft Hotline, and joined Microsoft in 2002 to provide support for Premier Customers. He has written several public articles, and developed tools and programs to be used by Microsoft customers and employees. Currently Burak works as a Technology Specialist for the sales department.


Inside SharePoint Updating Security Account Credentials
Pav Cherny

Code download available at: ChernySharePoint2009_03.exe (821 KB)

Contents
Services and Security Accounts
Services and Security Accounts
One Command for all Services
Going the Full Distance
Deploying and Using the Solution
Conclusion
Microsoft Windows SharePoint Services (WSS) 3.0 and Microsoft Office SharePoint Server (MOSS) 2007 push security manageability to the limit with services and worker processes that rely on domain user accounts to support the discretionary access control (DAC)-based security model of Windows Server. In the role of security accounts, domain user accounts have always struggled to meet enterprise needs. This applies to any client/server environment and even more so to SharePoint server farms, as each service in a farm maintains its own account information and imposes its own specific update procedures, regardless of other services that might use the same credentials. The account in question might be the same account in Active Directory, but you still have to update each service individually after a password change.
Of course, you first must remember all of the services that use an account. It can be challenging to follow security recommendations that suggest using separate domain accounts for SQL Server services, Central Administration and SharePoint Timer services, Search service and crawler, Shared Services Providers (SSPs), Web app pools, Single Sign-On service, user profile import, and Excel Services accounts.
And, of course, there are different strong passwords for each account and frequent password changes to keep track of. Wouldn't it be great to master this challenge without incurring administrative overhead?
Security Resource

Windows SharePoint Services Passwords Web Site
In this the second installment of a two-part series, I discuss aspects of SharePoint security, specifically security account maintenance, and introduce a solution to automate password changes to achieve better security and lower the administrative burden.
The underlying idea is relatively simple: a custom solution can obtain all security account names and passwords by using the SharePoint administrative object model. The solution can use this information to log on to Active Directory, change the corresponding passwords via Active Directory Service Interfaces (ADSI), and update all affected services in the local server farm.
In this way, SharePoint administrators don't have to deal with security account passwords anymore. However, implementing the idea was not so simple. In the end, I found myself creating several components, including Stsadm.exe command extensions, application pages for the SharePoint 3.0 Central Administration site, a SharePoint-integrated Windows service, and a basic programming interface to normalize password changes across all types of SharePoint services.
I didn't have enough time to cover all MOSS services yet, but the current prototype supports WSS 3.0. I have created a Web site at sppwd.com that will, in the near future, provide the MOSS components and other updates as well as further documentation of features and programming interfaces.
The current prototype is for test purposes only and is not to be used in production environments. Not fully tested, it nevertheless demonstrates that SharePoint security account maintenance does not have to increase administrative overhead. The companion material for this column, available at 2009 TechNet Code Downloads, includes worksheets, compiled assemblies, and source code.

Services and Security Accounts
Have you ever wondered why you need to use so many different commands to update SharePoint security accounts after a password change in Active Directory? Then check out the article "How to Change Service Accounts and Service Account Passwords in SharePoint Server 2007 and in Windows SharePoint Services 3.0."
It describes five different commands (updateaccountpassword, spsearch/farmserviceaccount, spsearch/farmcontentaccessaccount, updatefarmcredentials, and editssp/ssplogin), and it still doesn't cover all aspects.
Moreover, the article's sample script, while useful as a template, showcases a weak security configuration because it assumes you use the same account and password for all services in the farm. Try adapting this script to a farm environment where each service and application pool uses a different user account and password, and you can experience a great scripting challenge. Maintaining system security through scripts isn't easy in a SharePoint farm.
The reason for the complexities is buried deep within the SharePoint security design. As you learn by using the stsadm -o enumservices command, SharePoint relies on a number of services, and each service has different security dependencies.
If you look up the type name that the enumservices command returns for each service in the WSS 3.0 SDK, you'll find that some of these services use no security accounts, while others may use a single security account or require multiple accounts. For example, messaging-related services and the diagnostics service are not associated with security account information, the SharePoint Timer service uses a single security account, the Search service has a service account as well as a crawler account, and the Web app service can have as many security accounts as there are application pools.
And there is more. The SharePoint Administration Service, for example, must use the local system account, so it doesn't require a domain security account even in a SharePoint farm. Some solutions can also introduce their own services, such as Microsoft Office Project Server (MOPS) 2007. The sky is the limit, considering that you can also have any number of custom solutions with varying security requirements.
Of course, there's no way to enforce common update procedures across such a diverse portfolio of services, so it's no surprise that SharePoint features a rich set of update commands. Essentially, every solution must provide its own individual tools and update procedures, increasing the administrative overhead in proportion to the number of services in the SharePoint environment. Figure 1 illustrates the relationship between SharePoint services and security accounts as well as the applicable update commands.
Figure 1 Relationship between SharePoint services and security accounts

Services and Security Accounts
The arrangement of services and security accounts might seem confusing, but there is a hierarchical order enforced through the SharePoint object model, as illustrated in Figure 2. At the base of all SharePoint services is the SPService class. This class doesn't include a security account because, as mentioned earlier, not all services require credentials. Services that require credentials can inherit an identity from the SPWindowsService class or implement their own.
Figure 2 Inheritance hierarchies of SharePoint services
The SPSearchService class, for example, inherits a process identity from the SPWindowsService class and also maintains its own crawler account. The SPWebService class, on the other hand, doesn't need an SPWindowsServicebased process identity, so it inherits directly from the SPService class and maintains its own security accounts in the form of application pool identities.
There are many important facts to take away from the inheritance hierarchy. First and foremost, there aren't really that many different ways to deal with security accounts in a SharePoint farm. SharePoint services primarily use process identities or application pool identities. These identity types are very similar with respect to updating security information, because the SPApplicationPool class is derived from the SPProcessIdentity class.
Second, the identities of SharePoint services are available to custom scripts and administrative applications. It is possible to get to each individual SharePoint service through the SPService base class in order to access login names and passwords.
Third, the SharePoint object model already knows how to handle process identities and app pool identities. Among other things, the object model includes the logic to set and update passwords, so you don't need to reinvent the wheel when using custom tools. You only need to call the required methods, though this isn't without hurdles because the WSS SDK doesn't explain the dependencies very well.
Updating security accounts requires more than setting the Username and Password (or SecurePassword) properties of process identities (SPProcessIdentity) or application pool identities (SPApplicationPool) and calling the Update method. Doing so doesn't put the farm back into operational state. The Update method merely updates the password in the SharePoint configuration database, but it doesn't update the underlying services or app pools.
It is important to keep in mind that the affected resources exist outside of the SharePoint environment. Windows services maintain their security information in the database of the Service Control Manager (SCM), located in the registry on each server under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services.
Web apps, on the other hand, are resources of IIS. To update them, you must call the identity's Deploy method in addition to the Update method. The Deploy method triggers the SharePoint logic to update all servers in the farm by means of local API calls and SharePoint Timer jobs. It also changes the farm's credential key if your change happens to affect the password of the application pool for the Central Administration Web application (SPWebService.AdministrationService).
This password change also affects the SharePoint Timer service, which is tightly coupled with the administrative infrastructure, so you don't need to update the SharePoint Timer service directly. For details regarding the standard procedures to accomplish password changes in a farm environment with multiple servers, you should read my column from last month, "Maintaining Security Account Credentials."

One Command for all Services
Despite the complexities, the good news is that the SharePoint object model takes care of all the nitty-gritty update details in a server farm. We just need to take advantage of the existing capabilities in a custom Stsadm extension to implement a single update command for all services:
stsadm -o changepwd -user DOMAIN\Account -oldpwd old_p@ssw0rd
 -newpwd new_ p@ssw0rd
There is really no need for so many different update commands. After all, it is clear that you must change the password in all locations, including Active Directory, configuration database, Windows services database, IIS, and whatever other credential repositories a particular service might use.
It isn't an option to leave an outdated password behind. Having a command extension take care of all dependencies implies more consistent password changes across all affected resources and fewer password-related issues in the farm.
Besides, implementing an Stsadm extension is easy and fun. Just follow the steps outlined in the WSS SDK under the title "How to: Extend the STSADM Utility." I also recommend that you check out Gary Lapointe's blog for great examples and an impressive list of useful extensions that you might find helpful in your daily work as a SharePoint administrator.
With the Stsadm implementation details out of the way, we can concentrate our efforts on implementing the actual solution, which is difficult enough considering that SharePoint services can use any number of credentials. This can include process identities, application pool identities, and other accounts.
There is just no way to know the security dependencies of every SharePoint service up front. You can get away with the standard WSS and MOSS services, but a truly useful solution should also support custom services with varying requirements.
Dealing with variety is best accomplished through an API. The API decouples the command extension from the underlying services and in this way enables developers to plug in their own components that contain the logic to carry out password changes for their services.
I call these pluggable components service proxies. By relying on these proxy components, the command extension can accommodate any service, developers don't have to deliver additional password update tools anymore, and administrators don't have to deal with security complexities of underlying services any longer. Thus the administrative burden to maintain security accounts in a SharePoint environment decreases.
Our service proxy API must accomplish two basic things: it must enable the command extension to determine the security accounts of every supported service, and it must enable the command extension to update the associated passwords. Accordingly, the API requires two methods: ResolveIdentities and ChangePassword.
First, the command extension enumerates all services in the farm by using the SPFarm.Local.Services collection. For every service type, the command extension also dynamically loads a service proxy, registered for the service in an XML-based configuration file that follows the passwordproxies.*.xml naming convention (such as passwordproxies.WSSProxies.xml).
Then, the command extension calls the ResolveIdentities method of the registered service proxy, passing along a reference to the service object. The proxy component extracts the desired security accounts from the underlying service and returns this information to the command extension.
The result is an association between security accounts and services that is the reverse of the association established in the SharePoint object model. Instead of services being the parents of security accounts, security accounts are now the parents of services, as illustrated in Figure 3. This architecture reflects the actual relationship between services and security accounts better.
Figure 3 Reversing the relationship between security accounts and SharePoint services
More important, the command extension can now update the security accounts in Active Directory and then iterate through all dependent service objects to call the ChangePassword method of the corresponding proxies to update the password.
Again, the proxy components contain the service-specific logic necessary to carry out the password changes. The command extension itself does not deal with service-specific implementation details.
If you are interested in the details, check out the SPPwdServiceProxy.cs file in the companion material. It defines the proxy API by means of an abstract SPPwdServiceProxy class with its two methods, ResolveIdentities and ChangePassword. For implementation examples, see the class definitions in the WSSProxies class library.
The WSSProxies library illustrates how to use the service proxy API to perform password changes for the standard WSS 3.0 services. It isn't complicated to change security account passwords programmatically. All you need are three lines of code for process identities and the same three lines for application pool identities. The SharePoint object model does the rest.
Only the crawl account of the SPSearchService class poses a challenge because Microsoft marked the crawl password write only, so you can't read it with ordinary methods. This makes it hard for solution developers to create security solutions.

Going the Full Distance
With a single command extension covering all services, let us focus our attention on a couple of additional improvement opportunities. The first one is to eliminate the necessity of specifying passwords in clear text at a command prompt, which is not a secure practice. Even the simplest password box in the graphical user interface would mask this information.
Another opportunity is to increase the complexity of passwords without increasing the administrative burden. Perhaps passwords with seven random alphanumeric characters were once considered secure, but that assumption was established a long time ago and probably does not hold true for security accounts now.
How about using 50 or more chars for important resources, such as SharePoint security accounts: 3ZK2AQUuqZ7/M7NBIEvc{XKregSMaVmQgiZaZXikhL8E{dQuwyQ for the farm account; TA3pIa7yUyJikc6FxTFl=K9EQcb8lBnhp8ej03lt3+mA=7aqgKA for the default Web app; PXMzzAxrHvO/L9MZyd0SkVuMv9/co0ocluYCq/4TID/n+DLjXYA for the Search service account; and qjoNlEvOX$7vbEjrnDd5lXLPYvZEFfgRpij$8amSbEVpj2O474Q for the crawler account?
It strikes me as funny to imagine an admin entering these types of passwords manually. Another improvement opportunity relates to security checks. By default, SharePoint doesn't warn you about weak security configurations, such as application pools having access to the IIS metabase or using the farm account as their security identity. A custom solution can perform these checks on a regular basis.
And finally, why do SharePoint admins have to deal with these passwords for security accounts? Attackers are perhaps the only ones interested in knowing these passwords. Administrators generally don't need to use them.
Of course, SharePoint offers a lot of options to tackle these opportunities. You can use scripts, but scripts usually handle passwords in clear text. You can use custom Timer jobs, which the SharePoint Timer service processes in scheduled intervals, but the Timer service already takes care of many tasks, including credential deployments.
It would be difficult to coordinate credential deployment jobs with password change jobs. It seemed better to implement a separate SharePoint service that utilizes the farm account as its process identity to gain full access to the SharePoint administrative object model.
Among other things, you can stop this service at any time without affecting other processes, and you can disable this service if you prefer to change passwords manually. The solution includes several tools for this purpose, such as Stsadm command extensions, a Windows application, and custom Central Administration application pages, as displayed in Figure 4.
Figure 4 SPPwd solution architecture
Essentially, all SPPwd apps rely on the same set of Stsadm extensions, so there is only one code path regardless of what tool you use. Through a layer of common business logic, the command extensions in conjunction with service proxies perform the actual processing, while the SPPwd applications use stub objects to load the command extensions dynamically at run time.
This loose coupling enables you to replace certain command extensions without having to modify the SPPwd applications. For example, if you prefer to use a different password generator, you can create a command extension, deploy it in the global assembly cache, and modify the genpwd command entry in the stsadmcommands.passwordmanagement.xml configuration file. The solution places it in the %ProgramFiles%\Common Files\Microsoft Shared\Web Server Extensions\12\Config folder according to Stsadm extensibility conventions.
The default generator creates those long passwords, which should be sufficient in most cases. Figure 5 lists the SPPwd command extensions with a short description of their purpose. You can also use the stsadm -help <extension> command to display further information about available parameters and command-line examples.
Figure 5 Stsadm command extensions for the SPPwd solution
Extension | Code File | Description
accesscheck | SPPwdAccessCheck.cs | Checks whether the current user or a specified account has read access to security-sensitive information in the IIS metabase and the local registry. The SPPwd service analyzes the results of these checks as well as the general security account configuration and writes warnings to the Application event log if it detects security weaknesses.
changepwd | SPPwdChangePwd.cs | Changes the password for the specified user account in Active Directory and all SharePoint services that use the account as a security identity.
genpwd | SPPwdGenerator.cs | Generates random passwords based on a cryptographic Random Number Generator (RNG) and hash algorithms that can be considered reasonably secure.
sppwdsetup | SPPwdServiceSetup.cs | Installs or uninstalls the Windows service on the local SharePoint server.
enumpoolaccounts | SPPwdAppPoolAccounts.cs | Lists the identities of the SharePoint Web applications as parents of their associated application pools. The SPPwd service uses this information to check for security weaknesses, such as application pools that share the same identity or that use the farm account.
enumserviceids | SPPwdListServiceIds.cs | Lists the identities of the services available in the SharePoint server farm as parents of their associated services. The SPPwd service uses this information to retrieve the login name and current password of each service in order to use this information for Active Directory logons and carrying out password changes.
enumproxies | SPPwdServiceProxies.cs | Lists the SPPwdServiceProxy objects registered and loaded on the server. This tool is useful for developers who want to verify the configuration of their service proxies.
enumsppwdservers | SPPwdServerList.cs | Lists the fully qualified domain name of the SharePoint servers in the local farm, configured to run the SPPwd service. This information is helpful when configuring security accounts for automated password changes.
sppwdacctcfg | SPPwdAccountSettings.cs | Configures SPPwd-related settings for the specified security account in Active Directory. The SPPwd service does not process security accounts unless the account's extensionAttribute10 is set to the fully qualified domain name of the computer running the SPPwd service. In addition, the security account's description attribute must contain the phrase "This account is used only in the SharePoint farm: <Name of Farm>."
sppwdsvccfg | SPPwdConfig.cs | Displays or changes the system configuration of the SPPwd service. Settings include the configuration check interval, the maximum password age for security accounts, the level of detail for events written to the Application event log, and a parameter to disable Whatif mode explicitly. By default, the SPPwd service runs in Whatif mode to prevent accidental password changes. In Whatif mode the service only pretends to change passwords and reports the outcome of the operation, but it actually does not commit any changes.
Heartbeat | SPPwdCheckHeartbeat | Manages SharePoint Timer heartbeat jobs in a SharePoint server farm. The SPPwd solution uses these heartbeats to detect offline servers and prevents password changes in this case.

Deploying and Using the Solution
The worksheets in the companion material outline in detail how to deploy and use the SPPwd solution in a single-server environment as well as in a server farm. You only need to deploy the solution on one SharePoint server by using the standard addsolution and deploysolution Stsadm commands.
SharePoint then distributes the solution to all servers in the farm through Timer jobs. As soon as these jobs are completed, you can activate the solution feature to extend the Central Administration site and install the Windows service by using the sppwdsetup command extension.
The companion material includes a DeployTo.bat file to automate these tasks. Among other things, the batch file demonstrates how to wait for Timer jobs to complete before proceeding with further deployment steps.
By default, the SPPwd service is only available on the server where you run the DeployTo.bat file. You can configure the service to run on multiple SharePoint servers, but there is only one instance of a security account in Active Directory, and it imposes the following two requirements: only one SPPwd service instance can be authoritative for a particular security account, and the security account must not be used in multiple farms.
Having multiple service instances process the same account can lead to concurrent access problems and isn't necessary since SharePoint propagates credential updates in the local farm automatically. Shared security accounts aren't supported because the SPPwd service can't update security account information across multiple farms.
The SPPwd service only updates security accounts that specify the server's fully qualified domain name in the adminDescription attribute and that confirm in their description attribute that they're only used in the local SharePoint farm, as indicated in Figure 6. See the companion material for more regarding the configuration of security accounts and the SPPwd service to automate password changes.
Figure 6 SPPwd deployment and security account configuration
Conclusion
Security accounts are prime targets for attacks, because they can provide full access to all site collections and site data in a farm regardless of permissions and access controls defined at the SharePoint level. One basic strategy to prevent these attacks from succeeding is to use strong security account passwords and change them frequently.
This is challenging to accomplish because domain user accounts don't change their passwords on their own. You must perform the password changes manually or use an automated solution. Whichever way you choose, there are numerous dependencies that the SharePoint documentation and the WSS SDK don't describe very well.
You must update and deploy changed passwords, and there are additional concerns related to the farm account. For example, when you change the farm account password, you change the farm's credential key, and this affects the recoverability of the configuration database from backup.
Nevertheless, there is no alternative to changing the farm account password on a regular basis if you want to maintain system security in a SharePoint farm. Make sure you perform a backup after changing the farm account password.
Automating password changes is complicated despite the fact that the SharePoint object model includes the necessary logic to carry out credential updates. It might seem easy first glance, but even a script-based approach can quickly turn into a huge challenge. A full-featured solution based on the Microsoft .NET Framework and the SharePoint administrative object model is a good choice, but the best solution can only come directly from Microsoft in the form of additional system account innovations.
Almost 10 years ago, Microsoft modified the local system account to accommodate the needs of enterprise customers using Microsoft Exchange Server. This eventually resulted in the Network Service account with Windows Server 2003. But the Network Service account is not suitable for server farms, so we must still use domain user accounts and deal with the associated maintenance and security issues to the best of our abilities.

Pav Cherny is an IT expert and author specializing in Microsoft technologies for collaboration and unified communication. His publications include white papers, product manuals, and books with a focus on IT operations and system administration. Pav is President of Biblioso Corporation, a company that specializes in managed documentation and localization services.


Windows PowerShell Automating User Provisioning, Part 1
Don Jones

Contents
Setting Goals
Building the Initial Structure
Getting Input
Expansion
Coming Up Next
With this column, I am kicking off a four-part series on creating a practical, real-world, user-provisioning script in Windows PowerShell. In this first part, I'll focus on creating the structure for the script. Next month, I'll look at actually creating a new, mailbox-enabled user in Active Directory and Exchange Server 2007. The following month, I'll take care of creating home directories and applying the proper Access Control Lists (ACLs) to them. And in the final installment, I'll place the new user into groups and take care of populating additional Active Directory attributes.
Video
Don Jones kicks off a four part series looking at how you can use Windows PowerShell to create a user provisioning script. Watch Don demonstrate these techniques in this video.

Setting Goals
The trickiest part of user provisioning is deciding from where the initial data will come. How will I know what users to create? And where will I get their information, such as names, e-mail addresses, mailing address, department, and other details?
Nearly every environment will have a different answer, and so I will create a script that's capable of accepting input from a variety of places. That will make the script slightly more complicated, but it'll be worth the effort in the long run because the script will be more flexible. We also want to build a script capable of creating a hundred new users as easily as one—this is about automation, after all!

Building the Initial Structure
I do a decent amount of consulting with various companies, and a lot of the focus is on scripting and automation. Not surprisingly, I see a lot of scripts, and I've noticed that a common approach is for an administrator to just build a single provisioning script.
Over time, the administrator will modify the script to handle more and more tasks. That's not a bad approach, but by taking time up front to create a somewhat more modularized structure, you can create a script that's actually more flexible and easier to maintain. And this doesn't require much extra work.
I'm going to start with a central function named Provision. It's not actually going to do very much; it will accept a hashtable (or associative array) that contains the new user information, and then it will call a series of sub-functions that actually handle all of the provisioning tasks. Because this is Windows PowerShell, I want all of this to work on the pipeline. So I'm going to have it accept one hashtable for each new user, and I will enable it to accept a whole pipeline full of hashtables to create multiple users.
The basic function template looks like this:
Function Provision {
  PROCESS {
  }
}
Not very impressive, is it? With Windows PowerShell, it doesn't need to be. That PROCESS script block will execute once for each object that I pipe into the function. And within the PROCESS script block, I will use the $_ variable to access the current pipeline object.

Windows PowerShell Q&A

Q I looked up the Win32_OperatingSystem Windows Management Instrumentation (WMI) class on the MSDN Web site. It says the class contains service pack version information. When I run Get-WmiObject Win32_OperatingSystem in Windows PowerShell, no service pack information is shown. Why?
A The Windows PowerShell formatting subsystem selects a default subset of the properties in that class for display. One way to force it to show all of the properties is to use a formatting cmdlet to override those defaults:
Get-WmiObject Win32_OperatingSystem | Format-List *
Or, if you just want specific properties:
Get-WmiObject Win32_OperatingSystem |
Format-List BuildNumber,CSName,ServicePackMajorVersion

Getting Input
The reason I don't have the Provision function actually get any data on its own is that I want more flexibility, and I don't want to go back and change the function every time I want to adopt a new form of input. Instead, I will create two functions that get my new-user information—one from a CSV file and the other from a database. For now, I'll just work on the CSV-related function since CSV files are easy to create with Notepad or another text editor (or even Microsoft Excel and most database applications).
One trick about CSVs—especially if provided by someone less technically inclined—is that you can't rely on the file's column headers being the proper Active Directory attributes. That is, instead of column names such as sn and samAccountName, you're more likely to get column names such as Last Name and Logon Name. That's OK—Windows PowerShell can do the translation. I'll start by assuming a CSV file contains the following columns:
  • First Name
  • Last Name
  • City
  • Department
  • Job Title
  • Logon Name
  • Password
You can, of course, expand that list—I'll show you how it works in a moment. Using this list, a sample CSV file might look something like this:
First Name,Last Name,City,Department,Job  Title,Logon Name,Password
Don,Jones,Las Vegas,IT,Writer,donj,P@ssw0rd
Greg,Shields,Denver,IT,Administrator,gregs,  P@ssw0rd
I'll create a function named ProvisionInputCSV, have it accept a filename as an input parameter, and have it simply read the CSV file:
Function ProvisionInputCSV {
  Param ([string]$filename)
  Import-CSV $filename
}
I can run that function by itself, like so, just to make sure it's reading the CSV file:
ProvisionInputCSV c:\files\myinput.csv
Now I want to have the function translate each line of the CSV into a hashtable. And, rather than retaining the column header names from the CSV file, I want to translate those column headers into more Active Directory-acceptable attribute names. There are a number of ways to do that in Windows PowerShell, but I'm going to stick with an approach that's relatively simple: I use a foreach loop to process each line of the CSV file, one at a time. For each line of the file, I'll create a hashtable and write it out to the pipeline.
Take a look at my function, shown in Figure 1. There are a few points worth noting:
  • Within the foreach block, the $user variable contains a single user. The foreach construct runs through each line in the $users variable and automatically populates $user with the next one.
  • Because some of the column header names contain spaces, it's necessary that I enclose those names in quotation marks.
  • I've added another attribute, displayName, which is constructed from two of the CSV columns: First Name and Last Name.
  • Write-Output is used to write each hashtable to the pipeline.
Figure 1 Function using a foreach loop
Function ProvisionInputCSV {
  Param ([string]$filename)
  $users = Import-CSV $filename
  foreach ($user in $users) {
    $ht = @{'givenName'=$user."First Name";
            'sn'= $user."Last Name";
            'title'= $user."Job Title";
            'department'= $user.Department;
            'displayName'= $user."First Name" + " " + $user."Last Name";
            'city'= $user.City;
            'password'= $user.Password;
            'samAccountName'= $user."Logon Name"
           }
    Write-Output $ht
  }
}
The practical upshot of all this is that I can use one function to read the CSV file and transform its data into hashtables. The hashtables can then be piped to my provisioning function:
ProvisionInputCSV c:\data\myinput.csv | Provision
Since my Provision function accepts a standardized hashtable, I can create several different input-generation functions—ProvisionInputDatabase, ProvisionInputSpreadsheet, and so on.
As long as those functions output my standardized hashtable full of user data, the main Provision function will operate correctly. This approach means I can, in the future, use entirely new input sources for new user data—without having to modify the core Provision function.

Expansion
You can easily add more columns to your version of the CSV file to populate things such as phone numbers or whatever other data you like. You just need to make sure that you also expand the hashtable to contain that information. For example, let's say I want to add Description and Office to my CSV file. I'd simply expand the hashtable by adding some lines, as shown in Figure 2. In other words, you can use the basic structure I've provided to accommodate whatever requirements your environment has for the directory attributes of new user accounts.
Figure 2 Revised function
Function ProvisionInputCSV {
  Param ([string]$filename)
  $users = Import-CSV $filename
  foreach ($user in $users) {
    $ht = @{'givenName'=$user."First Name";
            'sn'= $user."Last Name";
            'title'= $user."Job Title";
            'department'= $user.Department;
            'displayName'= $user."First Name" + " " + $user."Last Name";
            'city'= $user.City;
            'password'= $user.Password;
            'samAccountName'= $user."Logon Name";
            'office' = $user.office;
            'description' = $user.description
           }
    Write-Output $ht
  }
}

Coming Up Next
Next month, I'll start populating the main Provision function by creating a sub-function that creates new user accounts. I'll give you two versions of that sub-function—one for folks who have Exchange Server 2007 (which is Windows PowerShell enabled) and another for folks who don't. At that point, you'll actually have a pretty usable script: It'll just create user accounts. But since that's one of the more time-consuming parts of dealing with new users, this function could help you to start saving time immediately.

Don Jones is a cofounder of Concentrated Technology where he blogs weekly about Windows PowerShell, SQL Server, App-V, and other topics. Contact him through his Web site.


Geek of All Trades Tools of the Trade
Greg Shields

Every industry has its technicians, and every technician has his bag of tools to help get the job done. The world of IT is no different. Whether you're a specialist focusing your skills on the perfection of a single service or someone whose job is to keep everything afloat simultaneously, you need tools just like the folks in other fields. Yet, unlike the tools used by your electrician or your dentist, those we use in IT aren't so much ones you can wrap your hands around. Rather, our tools are logical extensions of the otherwise manual actions we need to accomplish. These tools allow us to automatically or more rapidly accomplish an otherwise complex or time-consuming activity. We may not need a hammer and saw to build our computing environment, but most of us couldn't live a day without our Windows Sysinternals utilities.
With this in mind, this month I take a deep dive into the Microsoft TechNet site and its offshoots to locate some of the very best tools available. As an IT professional who seeks to make life easier at little to no cost, you're sure to appreciate these 19 free downloads. Note that some have already been featured in TechNet Magazine's Utility Spotlight column; in those cases, I'll link to those columns to offer you more information on how to use the particular tool.
ADMX Migrator Windows Vista and Windows Server 2008 change the Group Policy format from ADM to ADMX. ADMX's XML-based format is entirely different than the old syntax and can be challenging to work with in a text editor. If you've created custom ADM Group Policy files, this tool automatically upgrades those files to the new format. It also provides a way for you to create your own custom ADMX files through its graphical interface (see Figure 1).
Figure 1 ADMX Migrator
BITS Administration Utility Kicking off a traditional file transfer can significantly impact the performance of both machines involved with the transfer. Also, traditional transfers that are interrupted midstream usually need to be restarted from scratch. For these reasons, the Background Intelligent Transfer Service (BITS) was developed. Yet while BITS is natively available in technologies like Windows Server Update Services (WSUS) and Configuration Manager, many administrators don't realize they can use the BITS Administration Utility and a little scripting to initiate and manage their own robust file transfers.
Debug Diagnostic Tool Troubleshooting Windows crashes and hangs can be a notoriously difficult process if you don't have specialized training. The Debug Diagnostic Tool assists with this process by analyzing system resources both during and after the crash to identify and report on the root cause of the problem.
Group Policy Inventory A tool for Windows Server 2003 and earlier environments, Group Policy Inventory is designed to poll for Group Policy and Windows Management Instrumentation (WMI) information across multiple computers at once. The resulting information can identify installed software, the success of Group Policy Object (GPO) distribution, and hardware inventory, among other capabilities. One handy use for this tool is in testing out a candidate WMI filter before attaching it to a GPO.
Internet Explorer Administration Kit The IEAK has been around almost as long as Internet Explorer. Designed to be a comprehensive configuration control utility for Internet Explorer, this tool locks down virtually every Internet Explorer setting to those that are customized for your organization. If you want to lock down your users' home pages, connection profiles, and even customize the Internet Explorer logo, the IEAK provides the necessary tools for you to get the job done.
LimitLogin Some administrators in highly secure or specialized environments wish they could limit users to a specific number of concurrent logins. Particularly useful with Windows Server 2003 Terminal Servers, LimitLogin enables administrators to enforce concurrent login quotas while tracking all login information right within Active Directory itself.
Microsoft Baseline Security Analyzer A longtime favorite among security administrators and those in small environments, the MBSA scans systems in your environment for known security vulnerabilities and unsecure configurations. Unlike WSUS, which focuses strictly on the presence or absence of updates on a computer, MBSA goes an extra step by identifying where a configuration setting may be bad for system security while making suggestions towards how to resolve the problem.
Microsoft File Server Migration Toolkit If you've attempted to move or consolidate data within a large file server, you recognize that this process is no small feat. Maintaining file paths and permissions during a migration makes complicated what seems at first blush to be a simple file copy. Microsoft File Server Migration Toolkit (see Figure 2) eases this process by leveraging Distributed File System (DFS), Volume Shadow Copy service (VSS), and other technologies to assist with any large-scale file server migration project.
Figure 2 File Server Migration Wizard
Microsoft Security Assessment Tool More a pencil-and-paper examination than a technological marvel, the MSAT is a comprehensive multiple-choice test that helps small- and medium-sized businesses understand their security posture (see Figure 3). You'll want to take the time to answer its hundreds of questions to understand your level of risk and evaluate the security defenses that you have already implemented.
Figure 3 The Microsoft Security Assessment Tool
Microsoft SharedView Computers were supposed to bring about levels of collaboration never before seen in business. But that real-time collaboration only works if you've got the right technology underpinnings. This free tool provides a way for up to 15 people to work on the same documents together.
Microsoft Windows Server 2003 Performance Advisor Using Data Collector Sets, both W indows Vista and Windows Server 2008 include the native capability to view snapshots of system performance and specified configurations. Yet their technology was based on the Server Performance Advisor originally written for Windows Server 2003. This tool collects performance data with an eye towards generating diagnostic reports geared towards specific server roles such as Active Directory, IIS, DNS, Terminal Services, among others.
Robocopy GUI While command-line and scripting activities have always been a part an IT administrator's daily workflow, sometimes you just want a graphical interface to get the job done. For your advanced needs associated with file copies and transfers, the Robocopy GUI provides that graphical interface. Exposing all of the functionality available through Robocopy's command line, this GUI tool makes it easy to set up file transfers and mirrors.
searchSd Security access control lists (ACLs) that are assigned to objects in Active Directory are most often exposed by viewing the properties of that object. But in situations where you want to view those ACLs across dozens or hundreds of objects, right-clicking each object for its properties no longer makes sense. In such cases, searchSd is a handy tool that enumerates ACLs and owners for Active Directory objects. This tool is particularly powerful when logging the configuration of Active Directory and its security for audit purposes.
Virtual Machine Remote Control Plus If your environment makes use of Virtual Server 2005, you might lament its Web-based management UI. While great for occasional use, it's likely you wish for a rich client application to manage your Virtual Server workloads. Virtual Machine Remote Control Plus provides just that forms-based interface. Using this tool, you can remotely control virtual machines as well as manage their configuration, all within its single interface.
Web Capacity Analysis Tool If you work primarily with Web servers, chances are you have used the Web Capacity Analysis Tool (WCAT) before. If not, you may not be aware of its ability to simulate traffic against a Web server. WCAT is designed to be used with a set of candidate clients to generate hits against a Web server, with the goal of determining that server's load capacity. Fully customizable, this tool provides a useful platform for deploying tests against Web servers in your environment in order to identify how much load you can safely support.
Windows Automated Installation Kit Installing a single Windows operating system is as easy as Next, Next, Finish. But those few mouse clicks grow far too cumbersome when you have to install hundreds of instances of the OS. The Microsoft WAIK provides a comprehensive platform upon which to rapidly deploy customized OS instances.
Windows Installer Clean Up Utility The unification of application installation under the Windows Installer is a boon to software developers and administrators alike. But sometimes the Windows Installer doesn't properly clean up its messes, leaving a computer in an inconsistent state that can prevent further installations or uninstallations. Used with care, the Windows Installer Clean Up utility can assist the administrator by removing installation information left by Windows Installer.
Windows Memory Diagnostic Natively available in Windows Vista and Windows Server 2008, but a separate download for earlier versions of Windows, the Windows Memory Diagnostic provides a testing platform to verify the functionality of RAM hardware on your computer. If you fear that a low-level hardware failure is causing higher-level problems, run this tool to verify that your RAM hasn't gone bad.
Windows SteadyState Designed with lab or kiosk computers in mind, Windows SteadyState provides a way for you to restore a shared computer back to its original configuration through a simple power cycle. SteadyState protects shared computers by effectively turning them into stateless appliances that can revert to your desired configuration at any time.
The job of being a systems administrator is difficult. As a result, it's important to have just the right tools. These 19 free tools are all available from Microsoft and are all designed to ease the administration of file servers, Exchange servers, and even desktops in your IT environment today.

Greg Shields, MVP, is a co-founder and IT guru with Concentrated Technology. His latest book, Windows Server 2008: What's New/What's Changed is available through SAPIEN Press. Get to know him at www.ConcentratedTech.com.


Desktop Files Mitigating Circumstances
Wes Miller

Contents
I Love You
King COM
The Flash Drive Dilemma
What's the Point?
The term mitigate is defined generally as to "make less severe, serious, or painful." I've spent quite a bit of time in this column discussing technologies that can be used to mitigate problems, especially those related to security. Growing up, I learned many proverbs and parables that were meant to help reinforce good behavior—and I'm still a big believer in many of those lessons I learned. My favorite proverb is "An ounce of prevention is worth a pound of cure." And my favorite quote is by philosopher George Santayana: "Those who cannot remember the past are condemned to repeat it." Together these do a good job of expressing how I like to operate—and how I wish more technologies operated.
Unfortunately, you and I get to interact with technology at a level that most people don't get (have?) to. While this is great at forcing us to learn technology, all too often the technology doesn't behave the way it's supposed to behave. When that happens, we have to mitigate against it to ensure that further damage doesn't happen as a result of the failure.
This month, I'm going to take my column in a bit of a philosophical direction. Simply by reading the pages of TechNet Magazine, you've already proven yourself to be something of a technophile—so I may just be preaching to the people who already agree with me here. Still, the points I bring up in this month's column are important enough to underscore.
I've mentioned before that the technology I work on (security and whitelisting) is a bit more of a preventative than is the standard technology that's been used to deal with malware for the last 25 years, which essentially compiled blacklists of signatures of known malware. The preventative approach can be a pretty avant-garde road to go down. But as I said in my November column ("Data Loss Prevention with Enterprise Rights Management "), it's all about what your real goal is. If you come into a conversation saying "I want to stop malware" without exploring other approaches, you'll simply follow the standard "find the bad stuff and eliminate it" path. You can see how easily this can become the norm—without ever really solving the problem.
Instead of that standard approach, I prefer the more pragmatic "What is the real problem that I'm trying to solve?" In this column, I'm going to discuss why I think this is useful. I'll look at a few random events, incidents, and technology problems, and show how the wrong approach is taken way too often as a reaction to them.

I Love YOu
Where were you on May 4, 2000? I worked at Slate.com—and all of a sudden, everyone loved me. It was the dawn of iloveyou.vbs. This little malware gem took advantage of three conditions to spread virally.
First, the malware used social engineering to get users to open the message. It came from someone you knew (you had to be in the sender's address book in order for it to be sent), so of course you had to find out if you were really loved.
Second, it was based upon the fundamentally correct notions that users a) don't know diddly about file extensions; b) don't bother to check file extensions (heck, they're hidden by default in Windows); and c) will click past anything warning them of potential badness (to see the dancing pigs, as Steve Riley likes to say). See Steve's blog, Steve Riley on Security, for more information.
Third, it took advantage of a fundamental architectural flaw, a flaw so apparent it should have been caught before the product with the flaw shipped. But it wasn't caught—so the malware could intrude and then spread very rapidly. ILOVEYOU worked by running Windows Script Host, harvesting the user's address book, and then sending e-mail to everyone in the victim's address book. As long as those in the address book also ran Microsoft Office Outlook on Windows and fell for the social engineering component of the virus, the process continued.
So where was the flaw? C'mon, give it a guess. Ready? The flaw was in Outlook, caused by two fundamental problems. When Outlook was originally designed, as with Internet Explorer 3.0 before it, COM and ActiveX were becoming all the rage—so you could quickly and easily reuse components of one application in another. Outlook, however, was far too trusting regarding who could call its COM object model. Inbound, completely unsecured documents—let alone e-mail content—should never have been able to even look in the address book, much less harvest it completely and then send e-mail. Sure, there are scenarios where it makes sense for an incoming e-mail to automatically send an e-mail response. But that's the exception—far from the rule.
Security in Outlook was subsequently tightened so that it now asks users when an application wants to query the address book or programmatically send mail (see Customize Programmatic Settings in Outlook 2007). That was an important step in the right direction. Users are also asked whether they want to grant permissions for the application—because, frankly, we all know what happens if a user really wants to see those dancing pigs.
You know what the mitigation most likely to be put in place was while users waited for Outlook to be fixed? Killing Windows Script Host (WSH). Beginning in 2000, like no other time in my career, one of the most frequent questions I got was, "My customer wants to remove WSH from Windows—how can this be done?" What a sorry state—an incredibly powerful scripting language was threatened due to drive-by malware that was enabled by security flaws.
I am, of course, a big fan of WSH. I think it's a great tool and that Windows PowerShell actually has a ways to go before it can replace WSH (though that's another column topic for another day). But my point is that WSH in and of itself is not a security hole. Eliminating one component because of the flaws in another is not an effective way to manage things. Still, it is very important that you secure your operating system, Web browser, and e-mail client (especially if it is COM enabled—ahem) to ensure that they cannot take advantage of WSH in a negative way.

King COM
In 1994, Microsoft released ActiveX, and the world seemed to take two opposing views: it was pure evil and would cause the downfall of the Internet, or it was a great, powerful tool and would make the browser into a real platform. ActiveX in and of itself is not a huge exploit waiting to happen. In fact, Microsoft did a pretty good job of implementing security for ActiveX in Internet Explorer—though, of course, it has been further hardened over the years as the rest of Windows has.
Nevertheless, one of my favorite Web searches is "2008 buffer overflow ActiveX." Go ahead—try it. You can change the year, if you like, to see how each year has gone. Why do I find this interesting? It's because Internet Explorer and ActiveX controls have unfortunately become the poster children for security vulnerabilities, deserved or not.
We face somewhat similar problems in the world of whitelisting software. Sure you can try to secure a system by only allowing code to run that's already on the PC, but suppose there are exploits in that code? You can get owned just as well as if you had no security software on the system. Just as with buffer overflows, controls that have wrongly been marked as "Safe for Scripting" become giant holes for hackers to take advantage of.
Why do I bring up the buffer overflow aspect here? Because this problem generated a response similar to the WSH/Outlook behavior noted earlier. Instead of blame attaching to vendors for not performing decent threat modeling and buffer-overflow detection and for incorrectly marking a control as Safe for Scripting, ActiveX itself became the culprit.
Perhaps it's fair. If Microsoft had implemented a better sandbox (as has been done to a degree in Windows Vista via Protected Mode) or if Microsoft had simply not allowed Safe for Scripting, we would not have these problems. And ActiveX would probably be more widely spread—or at least more widely tolerated.
Unfortunately, we do have these problems—and the ActiveX kill-bit (see Figure 1) has become something with which admins are all too familiar. See "How to stop an ActiveX control from running in Internet Explorer" for a description of how to programmatically kill any ActiveX control that is perceived as a threat. Controls check this registry entry before instantiation to see if they are allowed to run.
Figure 1 You can prevent an ActiveX control from running by setting the killbit so that the control is not called by Internet Explorer
The reality is that if you want to perform certain tasks from within Internet Explorer, such as querying a registry key, interacting with hardware or another application, or interacting with user data on a Windows PC, you basically have no choice except an ActiveX control. And creating a control—properly designed, threat modeled, developed, tested, and signed (whew)—can be a rather foreboding task. But it honestly shouldn't be viewed as a bad thing or as a giant security hole (unless you skip or short-circuit those steps). Oh, and about Safe for Scripting—if you're developing a control, and you have to have it safe for scripting, don't. Really. Not unless you have no other choice.
That said, how do you mitigate against bad ActiveX controls? The fans of other browsers will gleefully tell you "My browser doesn't have those kinds of exploits," but that's naive. Internet Explorer on Windows is designed very well, but it has flaws. All software has flaws. Running Web browser B because you believe Web browser A has flaws is usually grounded in zeal—not in actual security. There have been security flaws found in every major browser and in every major ActiveX control. The answer?
  • Keep your systems up-to-date.
  • Run anti-malware and antivirus tools—including the Microsoft Malicious Software Removal Tool.
  • Use kill-bits to disable ActiveX controls that have vulnerabilities, and re-enable the controls when they are fixed. The site ultimatewindowssecurity.com/killbit.asp offers a handy how-to on using Group Policy to push out kill-bits.
The upshot is that though you can disable ActiveX controls to the point that they won't run (see Figure 2), there will still be exploits—even if you use another Web browser. You need to learn the attack surface of whatever software you do decide to run. Simply avoiding Internet Explorer doesn't make you malware proof; it just makes you resistant to malware that targets Internet Explorer.
Figure 2 Managing ActiveX controls in Internet Explorer

The Flash Drive Dilemma
Many customers have huge concerns about USB flash drives, more so than almost any other technology. Why? When I talk to our customers, it comes down to two issues. First, USB flash drives are easy targets for social engineering, or any other means, trying to get malware onto computers (this really applies to targeted malware, the kind that traditional audio visual software can't catch until it's too late). Second, it is all too easy for sensitive data to walk out of the office on a tiny USB drive. That's why I'm such a big fan of Information Rights Management (IRM) and other Digital Rights Management (DRM) techniques that can truly prevent data loss. Clearly the real problem is not the USB flash drive itself; it's the way these drives can be used.
So rather than using epoxy to glue the USB ports shut (I've actually heard of that being done) or trying to block the hardware via Group Policy or third-party software, what can you do? Stopping targeted malware is difficult, something you can really only approach via Group Policy Software Restriction Policies, whitelisting, or other means of restricting code to run only from the system drive, network drive, or the like.
As for stopping data loss, that will probably involve some form of IRM/DRM. Still, anytime I have to talk to customers about USB flash drives (or any type of malware, for that matter) I tend to quote my first TechNet Magazine article ("Reduce Your Risk: 10 Security Rules To Live By"), "Your enterprise is only as secure as your least and most technical users." By that I mean that an end user who really wants to run a piece of software will find a way, just as an end user who really wants to share confidential information will also find a way to do so.
Mark Russinovich on Security

Circumventing Group Policy as an Administrator

Circumventing Group Policy as a Limited User

Defeating the Limitations of Power Users

What's the Point?
Years ago, when I worked at Winternals, Mark Russinovich researched and blogged on three topics pertinent to this discussion: defeating Group Policy (both as an administrator and as a limited user) and elevating privileges as a power user.
The "Mark Russinovich on Security" sidebar will direct you to the blog posts. These are great examples that demonstrate just how easy it is for a user to break free of policy or security constraints. Frustrated users often react to being locked down by eventually being willing to violate constraints—whether software, hardware, or policy based.
The three issues referenced in the sidebar have been concerns for some time. They are representative of the kinds of problems we all have to work around in our daily lives in a Windows ecosystem. The trouble is that mitigating against vulnerabilities, flaws, and software imperfections requires more than just reaction. It requires pragmatic thought about the real problem, which usually involves a good grasp of threat modeling and a willingness to accept that short-circuiting the immediate issue may cause a bigger fire than if you dealt with the real problem from the beginning.
A much better idea is to approach every situation with an open mind and, knowing that there are problems against which you are going to have to mitigate, take a step back and think about what the root problem actually is instead of just reacting in a short-sighted manner.

Wes Miller is a Senior Technical Product Manager at CoreTrace in Austin, Texas. Previously, he worked at Winternals Software and as a Program Manager at Microsoft. Wes can be reached at technet@getwired.com.


Hey, Scripting Guy! Watch the Stopwatch
The Microsoft Scripting Guys

One of the things I always enjoyed about working in Mexico was the attitude toward time. Everything always got accomplished but nothing was ever really rushed. If my friend Miguel and I were on our way to the office and he suggested we check out a new coffee shop, that's what we did. If we were a few minutes late to the office, what did it matter? We had a nice cup of coffee, enjoyed each other's company, and saw a beautiful sunrise.
As much as I appreciate that lifestyle, things have changed and my personal life has now become quite regimented. I get up at 6:00 A.M., exercise for an hour, take a shower, eat breakfast, and I am in the office by 7:30 A.M. I catch myself looking at my watch dozens of times a day to ensure that I am keeping to my schedule. In Mexico, I did not even bother to wear a watch. Time just never seemed to enter the discussion.
Network administrators and consultants, in contrast, must always be aware of time: We need to schedule backups, compute service availability, and determine system uptime, downtime, and response time. For tracking time, it may be sufficient to click an icon, look at your watch, and count the seconds or minutes until the application opens. But what if you get interrupted during the timing of the event? I don't know about you, but if I get sidetracked during an activity, I tend to forget things.
Even though I could use the rotating bezel on my dive watch to mark the start time, there's still the need to subtract all those numbers—and if I am dealing with interruptions, results might not be reliable. Rather than using a regular watch or even a dive watch, what I really need is a stopwatch, one that tells how long the activity took and remembers how long it took the last time as well. That way, I could get some perspective on what my current results actually mean in terms of performance.
Luckily, the Microsoft .NET Framework has a StopWatch class, which I put to use in a script called Set-StopWatchRecordValues.ps1. This script times an activity and writes the results to the registry. When the script is run on subsequent occasions, it retrieves the previous value from the registry and tells you both the current time and the previous time.
The StopWatch class is part of the System.Diagnostics namespace. It has a static method called StartNew that will create and start a new StopWatch. To call a static method from a .NET Framework class, you put the path to the namespace and the name of the class in square brackets, followed by two colons and the name of the method. In our example, System.Diagnostics is the .NET Framework namespace, and StopWatch is the class. We also need a variable to hold the System.Diagnostics.StopWatch object that is returned by the method:
$sw = [system.diagnostics.stopwatch]::startNew()
Once you do this, you can use the $sw variable to display information about the running StopWatch; for example, you can pipe the results to the Format-List cmdlet to display the value of all the properties contained in the object:
PS C:\> $sw | Format-List -Property *

IsRunning           : True
Elapsed             : 00:00:22.5467175
ElapsedMilliseconds : 22546
ElapsedTicks        : 67472757628
StopWatch has a number of useful methods, which are displayed in Figure 1. The most important is the Stop method because when you use the StartNew static method, the StopWatch object is both created and started at the same time. Therefore, the action you are most likely to take is to stop the StopWatch object in order to see how long the activity took.
Figure 1 StopWatch methods
Name | Definition
Equals | System.Boolean Equals(Object obj)
GetHashCode | System.Int32 GetHashCode()
GetType | System.Type GetType()
get_Elapsed | System.TimeSpan get_Elapsed()
get_ElapsedMilliseconds | System.Int64 get_ElapsedMilliseconds()
get_ElapsedTicks | System.Int64 get_ElapsedTicks()
get_IsRunning | System.Boolean get_IsRunning()
Reset | System.Void Reset()
Start | System.Void Start()
Stop | System.Void Stop()
ToString | System.String ToString()

In the Set-StopWatchRecordValues.ps1﻿ script, we create four functions to create and manage the StopWatch object and to record the elapsed time in the registry. The first time the script is run, it creates a registry key and informs the user that there is no stored information, as you can see in Figure 2.
Figure 2 The new registry key has no stored information
The script then creates the registry property and stores the current running time in the registry, as shown in Figure 3. When the script is run subsequently, the registry data is retrieved, displayed, and updated, as shown in Figure 4.
Figure 3 The registry key that stores the current running time
Figure 4 Running the script again retrieves, displays, and updates registry data
The script uses a single parameter named $debug, which is a switched parameter, meaning it only does something when it is present. When you run the script with the –debug switch, the script prints out detailed information as found in Figure 5, such as whether the registry key was located, what action the script is getting ready﻿ to perform, and when it has finished performing the action.
Figure 5 Running the script with the –debug switch
To create a command-line parameter, you use the Param statement, like so:
Param([switch]$debug)
Following the Param statement, which needs to be the first non-commented line in the script, we create the first function. This function is named Set-StopWatch, and it is used to create and start, or to stop, the StopWatch. The value that is supplied for the function's $action input parameter determines what the function will do. The function declaration is shown here:
Function Set-StopWatch($action)
A switch statement is used to select the action that is performed. This is also where we meet our first debug statement. To write the debug information to the console prompt, we use the Write-Debug cmdlet. The cool thing about the Write-Debug cmdlet is that it automatically formats the text with yellow and black (this is configurable). The other cool thing is that it will only write stuff to the console if you tell it to. By default, Write-Debug does not print out anything to the console. The input variable to the Set-StopWatch function is $action. The Switch statement looks at the value of the $action variable to determine the action to take:
Write-Debug "Set-StopWatch action is $action
 Switch ($action)
Now we need to define the action that will take place. The first action will occur if the value of the $action variable is equal to Start. If it is, we use the StartNew static method from the System.Diagnostic.StopWatch class and store the resulting StopWatch object in the $sw variable. We also create a debug statement indicating that we are starting the timer but, remember, this will only be displayed if the script is started with the –debug switch:
{
  "Start" {

Write-Debug "Starting Timer"
              $script:sw = [system.diagnostics
                 .stopwatch]::StartNew()
             }
When $action matches stop, we write a debug statement that states we are stopping the timer. We then check to see if the registry key exists. If it does, we create a variable named $swv and set it equal to $null. We then print out another debug message:
"Stop" {
Write-Debug "Stopping Timer"
               If(Test-Path -path $path)
                  {
                    $swv = $null
Write-Debug "$path was found. Calling Get-StopWatchvalue"
Next, we call the Get-StopWatchvalue function and pass it the $swv variable we just created. In this code, we pass the variable by reference, which means that the function will assign a new value to the variable and we will use it outside of the function that assigns the value to it. To pass the variable by reference, we need to convert $swv to a reference type. We use [ref] to perform this conversion. Note that we had to create the $swv variable earlier because you can't cast the variable to a reference type if it doesn't exist:
Get-StopWatchvalue([ref]$swv)
Write-Debug "Get-StopWatchvalue swv was: $($swv)"
                  }
If the registry key does not exist, we write a couple of debug statements, create the $swv variable and set it to null, and then call the New-StopWatchKey function, which creates the registry key:
Else

                 {
Write-Debug "$path was not found"
                  $swv = $null

Write-Debug "$swv is null. Calling New-StopWatchKey"
                  New-StopWatchKey
After we return from the New-StopWatchKey function, we print another debug statement and call the Get-StopWatchvalue function. We also pass the $swv variable by reference ($swv will be used later to display the data that was retrieved from the registry):
Write-Debug "Obtaining default value from get-StopWatchvalue"
                 et-StopWatchvalue([ref]$swv)
                 }
Now we need to stop the StopWatch. We first use another debug statement to print out a stop message, and then we call the Stop method from the StopWatch object stored in the $sw variable. After we have stopped the StopWatch, we need to convert the System.TimeSpan object that is obtained via the Elapsed property to a string so we can store its value in the registry. We pass the string representation of the timespan object to the Set-StopWatchValue function as seen here:
Write-Debug "Stopping the stop watch"
               $script:sw.Stop()
Write-Debug "Converting stop watch to string, and calling
 Set-StopWatchValue"
                   Set-StopWatchValue($script:
                      sw.Elapsed.toString())
Now we are ready to print the output to the console. The first thing we do is tell how long it took for the command to run. We use the script-scoped $sw variable and obtain the Elapsed property. A subexpression is used to force the evaluation of the Elapsed property to return the timespan object.
This may seem a bit confusing until you understand there are two kinds of string characters in Windows PowerShell. The first are literal strings, which are represented with single quotation marks. With a literal string, what you see is what you get. This means that a variable will not be expanded inside single quotation marks:
PS C:\> $a = "this is a string"
PS C:\> "This is what is in $a"
This is what is in $a
When you use expanding strings, represented by double quotation marks, the value of the variable is expanded and printed out:
PS C:\> $a = "this is a string"
PS C:\> "This is what is in $a"
This is what is in this is a string
While frustrating at first, this can be used to your advantage to avoid concatenating strings and variables. When you are aware of the two strings, you can use the backtick character to suppress variable expansion when desired:
PS C:\> $a = "this is a string"
PS C:\> "This is what is in "$a: $a"
This is what is in $a: this is a string
If you did not have expanding strings, you would need to concatenate the output like this:
PS C:\> $a = "this is a string"
PS C:\> "This is what is in $a: " + $a
This is what is in $a: this is a string
So what does this have to with our code? When an object is expanded in an expanding string, it will tell you the name of the object. If you want to see the value, you need to create a subexpression by placing the object in parentheses and placing a dollar sign in front of it. This will force the evaluation of the object and return the default property to the command line as shown here:
PS C:\> "$sw.Elapsed"
System.Diagnostics.Stopwatch.Elapsed
PS C:\> "$($sw.Elapsed)"
00:00:07.5247519
In our output, we print a message that displays how long the command took, as well as the value that is stored in the $swv variable as shown here:
"The command took $($script:sw.Elapsed)"
"Previous command took: " + $swv
It is always a best practice when using the Switch statement to create a default action. If the script is not running with the –debug switch, the script will print out the value of the $action variable and tell the user to use either Start or Stop. If it is running with the debug switch, several different lines are printed. In any case, the script will exit by calling the exit command, as shown here:
Default {
                 if(!$debug) {"$action is not understood. Specify Start / Stop"}
Write-Debug "Entering default action. $action was specified."
Write-Debug "Action value must be either Start or Stop"
Write-Debug "Exiting script now"
                  Exit
               }
} #end Switch
} #end Set-StopWatch
Now we come to the New-StopWatchKey function, which is called when the script detects that the scripting registry key has not yet been created. The first thing the New-StopWatchKey function does is print out a debug message. It then uses the New-Item cmdlet to create the registry key. The resulting message from this is piped to the Out-Null cmdlet to avoid cluttering the display.
Another debug message is printed out, and then the registry property is created to hold the previous run time. To do this, we use the New-ItemProperty cmdlet. The resulting message from this cmdlet is also sent to the Out-Null cmdlet. We print out one more debug message and leave the function:
Function New-StopWatchKey()
{
 Write-Debug "Inside New-StopWatchKey. Creating new item $path"
New-Item -path $path -force |
out-null
Write-Debug "Creating new item property $property"
New-ItemProperty -Path $path "
-Name $property -PropertyType string -value "no data" |
 out-null
Write-Debug "Leaving New-StopWatchkey"
} #end New-StopWatchKey
Now we need to create the Get-StopWatchvalue function to read the data stored in the registry and assign the data to the $swv reference variable. To do this, we first print out a couple of debug messages, and then use the Get-ItemProperty cmdlet to create a custom Windows PowerShell object that we store in the $swValue variable. As you can see here, there are a number of properties contained in the object:
PS C:\> $swValue = Get-ItemProperty -Path HKCU:\Scripting\Stopwatch
PS C:\> $swValue

PSPath          : Microsoft.PowerShell.Core\Registry::HKEY_CURRENT_USER\Scripting\Stopwatch
PSParentPath    : Microsoft.PowerShell.Core\Registry::HKEY_CURRENT_USER\Scripting
PSChildName     : Stopwatch
PSDrive         : HKCU
PSProvider      : Microsoft.PowerShell.Core\Registry
PreviousCommand : 00:00:00.3153793
You do not have to use the intermediate variable to obtain the previous value property. You can use parentheses and query the property directly. This can be a bit confusing, but the syntax is valid, as you can see:
PS C:\> (Get-ItemProperty -Path HKCU:\Scripting\Stopwatch).PreviousCommand
00:00:00.3153793
After we have the custom object, we query the PreviousCommand property and assign it to the value property of the $swv reference type variable. A couple more debug statements and we are done with the Get-StopWatchvalue function:
Function Get-StopWatchvalue([ref]$swv)
{
Write-Debug "Inside Get-StopWatchvalue."
Write-Debug "Obtaining $path\$property"
$swValue = Get-ItemProperty -Path $path "
  -Name $property
$swv.value = $swValue.PreviousCommand
Write-Debug "Value of "$swv is $($swv.value)"
Write-Debug "Leaving Get-StopWatchvalue"
} #end Get-StopWatchvalue
Next, we want to write to the registry the amount of time the command took so we create the Set-StopWatchvalue function. This function accepts the value to be written to the registry in the variable $newSwv. We write a couple of debug statements, and then call the Set-ItemProperty cmdlet, giving it the path stored in the $path variable, the name of the registry property stored in the $property variable, and the value that is stored in the $newSwv variable. We then print out one more debug message, and leave the Set-StopWatchValue function:
Function Set-StopWatchvalue($newSwv)
{
Write-Debug "Inside Set-StopWatchvalue"
Write-Debug "setting $path\$property to $newSwv"
Set-ItemProperty -Path $path "
-Name $property -Value $newSwv
Write-Debug "Leaving Set-StopWatchvalue"
} #end Set-StopWatchvalue
Now we have created all the functions required for the script. The entry point of the script first tests to see if the $debug variable is present. If it is, the script was run with the –debug switch and we change the value of the $DebugPreference automatic variable to "continue." By default, the $DebugPreference variable is set to silently continue, which means no debug messages will be displayed by the Write-Debug cmdlet.
In our script, we want to store the StopWatch times in a registry key under the HKEY_Current_User hive named Scripting\Stopwatch. We use a property named PreviousCommand. Each of these is assigned to the appropriate variables. The first thing we do after initializing the variables is call the Set-StopWatch function with Start for the action. After that function runs, we call the Get-Process cmdlet:
if($debug) { $DebugPreference = "continue" }
$path = "HKCU:\Scripting\Stopwatch"
$property = "PreviousCommand"
Set-StopWatch "Start"
Get-Process
If you are using this script to time various activities, this is where you would add what you need. You could even call a script at this point or include any number of commands to suit your needs.
If the $debug variable does not exist, the script is running in normal mode. In that case, we don't need to see the results of calling the Get-Process cmdlet on the screen because we are only interested in timing the activity. We therefore use the not operator (the exclamation mark, bat and ball, whatever you want to call it) to indicate that if there's no debug variable, we'll clear the screen using the Clear-Host Windows PowerShell function. Finally, we call the Set-StopWatch function with the Stop action to bring things to a halt:
if(!$debug) {Clear-Host}
Set-StopWatch "Stop"
Figure 6 shows the complete Set-StopWatchRecordValues.ps1 script.
Figure 6 Set-StopWatchRecordValues.ps1
Param([switch]$debug)
Function Set-StopWatch($action)
{
Write-Debug “Set-StopWatch action is $action”
 Switch ($action)
 {
  “Start” {
Write-Debug “Starting Timer”
               $script:sw = [system.diagnostics.stopwatch]::StartNew()
            }
  “Stop” {
Write-Debug “Stopping Timer”
               If(Test-Path -path $path)
                  {
                    $swv = $null
Write-Debug “$path was found. Calling Get-StopWatchvalue”
                    Get-StopWatchvalue([ref]$swv)
Write-Debug “Get-StopWatchvalue swv was: $($swv)”
                   }
               Else
                 {
Write-Debug “$path was not found”
                 $swv = $null
Write-Debug “$swv is null. Calling New-StopWatchKey”
                 New-StopWatchKey
Write-Debug “Obtaining default value from get-StopWatchvalue”
                 Get-StopWatchvalue([ref]$swv)
                }
Write-Debug “Stopping the stop watch”
               $script:sw.Stop()
Write-Debug “Converting stop watch to string, and calling Set-StopWatchValue”
               Set-StopWatchValue($script:sw.Elapsed.toString())
               “The command took $($script:sw.Elapsed)”
               “Previous command took: “ + $swv
              }
      Default {
                  if(!$debug) {“$action is not understood. Specify Start / Stop”}
Write-Debug “Entering default action. $action was specified.”
Write-Debug “Action value must be either Start or Stop”
Write-Debug “Exiting script now”
                 Exit
              }
 } #end Switch
} #end Set-StopWatch

Function New-StopWatchKey()
{
Write-Debug “Inside New-StopWatchKey. Creating new item $path”
 New-Item -path $path -force |
 out-null
Write-Debug “Creating new item property $property”
 New-ItemProperty -Path $path `
 -Name $property -PropertyType string -value “no data” |
 out-null
Write-Debug “Leaving New-StopWatchkey”
} #end New-StopWatchKey

Function Get-StopWatchvalue([ref]$swv)
{
Write-Debug “Inside Get-StopWatchvalue.”
Write-Debug “Obtaining $path\$property”
 $swValue = Get-ItemProperty -Path $path `
  -Name $property
 $swv.value = $swValue.PreviousCommand
Write-Debug “Value of `$swv is $($swv.value)”
Write-Debug “Leaving Get-StopWatchvalue”
} #end Get-StopWatchvalue

Function Set-StopWatchvalue($newSwv)
{
Write-Debug “Inside Set-StopWatchvalue”
Write-Debug “setting $path\$property to $newSwv”
 Set-ItemProperty -Path $path `
 -Name $property -Value $newSwv
Write-Debug “Leaving Set-StopWatchvalue”
} #end Set-StopWatchvalue

# *** entry point ***

if($debug) { $DebugPreference = “continue” }
$path = “HKCU:\Scripting\Stopwatch”
$property = “PreviousCommand”
Set-StopWatch “Start”
Get-Process
if(!$debug) {Clear-Host}
Set-StopWatch “Stop”
I hope you have enjoyed this excursion into the StopWatch class. Come over to the TechNet Script Center and check out our daily "Hey, Scripting Guy!" articles.

Ed Wilson is a well-known scripting expert. He has written and published eight books on the Microsoft Press imprint, including five on Microsoft Windows scripting, and is currently working on a Windows PowerShell best practices book. Ed holds more than 20 industry certifications, including Microsoft Certified Systems Engineer (MCSE) and Certified Information Systems Security Professional (CISSP). In his spare time he enjoys woodworking, underwater photography, and scuba diving. And tea.

Craig Liebendorfer is a wordsmith and longtime Microsoft Web editor. Craig still can't believe there's a job that pays him to work with words every day. One of his favorite things is irreverent humor, so he should fit right in here. He considers his greatest accomplishment in life to be his magnificent daughter.


Field Notes Listening to the User
Vivek Bhaskaran

For most medium to large businesses, information technology (IT) is usually defined as a cost center. This is evident every day, as IT teams are asked to justify their existence. With the current price restrictions due to the downturn in the economy, the role of IT in business decision making is being questioned at the most basic level.
Companies Using These Techniques
Here are some actual examples of how several companies are using collaboration, feedback, and suggestion sharing:
  1. ChoiceHotels IdeaScale: I was personally involved with the launch of the ChoiceHotels IdeaScale portal. ChoiceHotels had more than 60 new ideas posted in the first 24 hours following an e-mail invitation to 1,500 users. More than 400 users signed up to post, comment, or vote on ideas. The level of commenting and activity on the idea portal itself gives a clear indication of how much the users like the concept of an open-access feedback portal.
  2. MyStarbucksIdeas: MyStarbucksIdeas launched with great fanfare—President and CEO Howard Schultz published a press release, and Starbucks received a lot of attention simply because it was agreeing to listen to its customers.
  3. Ubuntu Brainstorm: Ubuntu is one of the most popular Linux distributions in the market today. Its development team uses a collaborative feedback portal to gauge new ideas and implement them.
As with all departments, businesses are asking how IT can do more with less. IT has the unique advantage of being tethered to the customers as well as to various business units within an organization. But if IT wants to remain relevant and operational, it needs to become a source of opportunity for businesses rather than simply a cost center. The big question is how do IT departments bring about this shift in how they are perceived?
One of the fundamental tenets of efficient communication is the feedback loop. No one operates in a vacuum. Feedback of some sort is necessary, whether it's anecdotal or in the form of standardized metrics. On a personal level, we have mentors, friends, and advisors who can tell us how we are doing. Companies, however, must conduct surveys in order to actually connect with clients, not only to tap into their collective intelligence but also to let customers know that their opinions are valued.
The first rule of sales is listening, not talking. Good salespeople have the ability to listen well and then offer solutions that match customers' needs. IT must follow that model and become a listening agent that reacts to the fundamental needs of customers and proposes innovative solutions that can affect the bottom line.
Listening systems thus form the back channel of what is called the innovation feedback loop. In the post dot-com world, the big concept that has emerged is known as "democratization." Blogs have democratized publishing—anyone with a computer can publish content. YouTube has democratized videos—anyone with a cell phone or a webcam can produce and upload videos.
Innovation is fairly common here. If we think we need to get to a point of perpetual innovation, we need to democratize IT. Let everyone participate in global asynchronous brainstorming sessions and collect feedback at every participatory point. Engage by listening.
One of the often under-appreciated aspects of feedback and of any listening system is its ability to engage the audience. Most people, when asked the right way and at an opportune time, are willing to give feedback. At a core human and social level, giving feedback validates your own importance. Studies have shown that the mere act of asking customers for their opinion doubles profitability (see the study published in Harvard Business Review "How Surveys Influence Customers" at rfgmkt.com/How_Surveys_Influence_Customers.pdf).
IT should engage with customers to provide a platform for listening to the various constituents they serve. IT is in a unique position to distill feedback and data from divergent sources and then propose innovative solutions.

Vivek Bhaskaran is the Founder and CEO of Survey Analytics. With the mission to democratize feedback, Survey Analytics owns and operates QuestionPro.com, IdeaScale.com, and MicroPoll.com.


Blog Tales WSUS clients install updates properly but don’t send any status reports back to the server
J.C. Hornbeck

In which we search far and wide to bring you the best of the Microsoft blogs. Here's one from the WSUS Support Team Blog.
Here's a cool tip and a cool tool that was sent to me by Joe Tindale, one of the top Support Escalation Engineers in our WSUS group. If you find that your WSUS clients are not sending status updates back to the server then this is something you'll want to check out.

= = = = = = = = = = =
Issue: You may notice that your clients will check into WSUS and install updates properly but don't send any status reports back to the server even though you can see that events were being generated locally. If you review the IIS logs you may also see that the client IP addresses never attempt to post to the WSUS servers "reportingwebservice".
We saw the following in the windowsupdate.log so we know it was generating local reporting events:

2008-02-21 05:22:58:989 668 1408 Report REPORT EVENT: {91CFE792-1064-473B-8AA0-C9E392F2E76C} 2008-02-21 05:22:53:989-0500 1 162 101 {671ACCFF-0C42-4DDF-AF69-50DA8004EC29} 100 0 AutomaticUpdates Success Content Download Download succeeded.
2008-02-21 05:22:58:989 668 1408 Report REPORT EVENT: {1060A038-6F4D-49BB-9CA6-E02FADD13DE9} 2008-02-21 05:22:54:001-0500 1 188 102 {00000000-0000-0000-0000-000000000000} 0 0 AutomaticUpdates Success Content Install Installation Ready: The following updates are downloaded and ready for installation. This computer is currently scheduled to install these updates on ?Friday, ?February ?22, ?2008 at 3:00 AM: - Definition Update for Microsoft Forefront Client Security (Antimalware 1.27.6904.0)

What we didn't see was something like the following, which would tell us that the client was uploading those reporting events to the WSUS server:

2008-02-16 00:39:00:494 668 8d0 Report Uploading 2 events using cached cookie, reporting URL = http://some_WSUS_server/ReportingWebService/ReportingWebService.asmx 2008-02-16 00:39:00:932 668 8d0 Report Reporter successfully uploaded 2 events.

Even if you try forcing a report and taking a network trace, you'll never see any traffic to the reportingwebservice.
Note: You can force a report from the command line with the following: wuauclt /reportnow
Cause: This can occur if ConfigMgr 2007 had been previously installed on the server as a Software Update Point (SUP) and Automatic Update reporting events was set to "Do not create WSUS reporting events":
Note: These settings were added specifically for ConfigMgr 2007 to reduce the number of reporting events sent back to the WSUS server. This configuration sets a value within WSUS and then WSUS tells the Automatic Update agent on each client to configure reporting accordingly.

Resolution: In my case, ConfigMgr 2007 had already been uninstalled so we could not revert the setting back to "Create all WSUS reporting events" unless ConfigMgr 2007 was reinstalled, however the above settings are exposed via a "clientreportinglevel" property of "IUpdateServerConfiguration" so I wrote a tool to configure the various members of this property:
All Clients should send all reporting information to the server
None Clients should not report update status or activity reports to the server
StatusOnly Clients should send update status reports to the server, but not activity reports.
For more information on these properties see:
  • msdn2.microsoft.com/en-us/library/microsoft.updateservices.administration.clientreportinglevel(VS.85).aspx
  • msdn2.microsoft.com/en-us/library/microsoft.updateservices.administration.iupdateserverconfiguration.clientreportinglevel(VS.85).aspx
The tool I wrote has a "/?" option that will display the help menu. It first displays the current reporting level and then gives you the options to change the reporting level:

C:\Users\Administrator\Desktop>WSUS_Reporting_Level.exe /?

Current Reporting Level: All

Please enter a numeric option:
Press '1' to set the client reporting level to 'ALL'.
Press '2' to set the client reporting level to 'NONE'.
Press '3' to set the client reporting level to 'STATUS ONLY'.
Press '4' to exit.
Once you set the clientreportinglevel to "All" the clients should start to send status reports within a short period of time.
To download my WSUS_Reporting_Level tool visit codeplex.com/WSUS/Release/ProjectReleases.aspx? ReleaseId=19272.
= = = = = = = = = = =

Keep in mind that the standard disclaimers apply (e.g. Microsoft has not fully tested this tool, use at your own risk, we make no warranties or guarantees as to the suitability of this tool, etc. etc.).
Thanks Joe!

J.C. Hornbeck, Manageability Knowledge Engineer


Windows Confidential The Forgotten Hotkey
Raymond Chen

Originally, Windows came with just a single task-switching hotkey: Alt+Tab. And this is your grandfather's Alt+Tab—uphill both ways. The keystrokes may be the same, but the experience for the user was quite different. There was no fancy Alt+Tab window. Instead, each time you pressed the Tab key, a different program received focus. And minimized applications were not opened; you had to open them yourself after you released the Alt key.
The Alt+Tab functionality in Windows 2.0 took us closer to the Alt+Tab behavior we have today. Overlapping windows were maintained in a front-to-back list (known as the z-order), and each tap of the Tab key selected the next window, temporarily bringing it to the front so you could see it.
Alt+Tab in Windows Vista offers live thumbnails
When you released the Alt key, the window you selected was raised to the top of the window stack. For example, if your window stack consisted of windows A, B, C, and D, using Alt+Tab to select window C would result in a new window stack order of C, A, B, D.
In Windows 3.0, the Alt+Tab hotkey got a face-lift. The effect on the z-order remained unchanged, but there was a new interface for getting there. Instead of temporarily showing each window, it merely showed you the window's icon and title. Only when you selected a window was it brought to the top of the window stack.
This was known as Fast Alt+Tab. For a time, you could choose whether you wanted the new design or the old one, but the new design was so much more popular that when support for the old design was silently removed with the release of Windows 95, nobody seemed to notice, much less complain.
Windows 95 and Windows Vista revealed more cosmetic tweaks, with Windows 95 adding a grid of icons and Windows Vista adding live thumbnails to help you zip to the window you want more quickly. (By the way, here's a little-known feature: in Windows Vista, you can use the mouse to click on the thumbnail to switch directly to that window.)
Unfortunately, with all this excitement attached to Alt+Tab, another hotkey has been woefully neglected. Windows 2.0 introduced the Alt+Esc hotkey. Whereas Alt+Tab lets you pick an application, Alt+Esc lets you cycle through them.
When you press Alt+Esc, the active window is sent to the bottom of the window stack, allowing the window beneath it in the z-order to become the new active window. And if the next window is a minimized window, it stays minimized. While this may sound like an annoyance, it is actually a useful device, as it lets you skip past minimized applications without having to open them.
Say the window stack consists of windows A, B, C, and D, for example. Pressing Alt+Esc will push window A to the bottom (resulting in a stack order of B, C, D, A). Pressing it again will push window B to the bottom (resulting in C, D, A, B). Since Alt+Esc doesn't open minimized windows, if window B were minimized, it would remain so.
Adding the shift key to the Alt+Esc sequence does the reverse: the bottom window from the stack is brought to the top (but not opened). You can switch between two windows by putting one at the top of the window stack, putting another at the bottom, and then using Alt+Esc and Alt+Shift+Esc to switch between them.
While Alt+Tab got all the attention during the evolution of Windows, poor little Alt+Esc sat on the sidelines, sobbing quietly to itself for having been neglected all these years. But Alt+Esc's relative neglect has also been an advantage. While many developers write programs that attempt to enhance the Alt+Tab user interface, nobody messes with Alt+Esc.
Like a crystal radio during a power outage, Alt+Esc comes to the rescue when your Alt+Tab and other task-switching enhancements stop working. If your Alt+Tab enhancement has gone haywire and a bad shell extension has messed up your taskbar, don't despair. You can then dig into your bag of tricks and pull out Alt+Esc, the backup task switcher hotkey that's there when you need it, because it never occurs to anybody to interfere with it.

Raymond Chen's Web site, The Old New Thing, and identically titled book (Addison-Wesley, 2007) deal with Windows history, Win32 programming, and exploding coffee machines.