Jeff Schertz: Posts

External Live Meeting Only with OCS

Jeff Schertz — Thu, 04 Jun 2009 19:54:01 GMT

Body:

One of the biggest cost-saving benefits of Office Communications Server 2007 has been the integrated Web Conferencing features, a.k.a. Live Meeting. Many companies currently pay for off-site host conferencing services like Microsoft's own hosted Live Meeting, or WebEx just to name a few. In the same way that R2’s Dial-In Conferencing can reduce costs by eliminating the need for a hosted phone bridge service, all versions of OCS can offer the same cost-cutting advantages by bringing Live Meeting services in house.

One example are organizations who already have a limited LCS deployment in-house but due to various internal political issues are not able to deploy IM services to the company as a whole, either inside or out. With the addition of a simple, yet robust OCS deployment it is possible to configure OCS to support only Web Conferencing for external users.

The approach used for a specific OCS 2007 R2 deployment included:

A single Enterprise Edition Front-End Consolidated Server
- No Hardware Load Balancer is required
- No Director
A Standard Edition Consolidated Edge Server
- (2) Network cards for separate internal and external roles
- Separate, unique IP subnetworks for the internal and external interfaces
- A single firewall with separate ports and rule-bases for each Edge interfaces
- No Reverse HTTPS Proxy deployed (can be added at a later date to support shared content download)

Internal Deployment

The internal deployment follows the standard installation and configuration steps; nothing out of the ordinary is required here. The basic SRV and A DNS records are setup to support Automatic Configuration and a pool record (using the IP address of the Front-End server itself). Certificate deployment is standard. If migrating users from LCS then make sure to install a certificate on the LCS server (if not already deployed) so that MTLS server-to-server communications will work correctly between LCS and OCS services.

Once everything is installed then you will need to configure the Web Conferencing policies to allow users rights to start conferences and (if desired) allow anonymous users to join.

The one major caveat during server configuration is to make sure and do not leave the External Web Farm FQDN blank during the Enterprise Pool creation (or Standard Edition server configuration). Even though there will not be a reverse proxy configured and thus no connectivity into the internal Web Components IIS site, and thus no real need for a defined external URL, it wont work. Once everything is deployed external clients will simply not be able to login to Live Meeting as the lack of a defined external Web Farm FQDN causes OCS to ‘give up’ and basically not allow external Web Conferencing connections. External Communicator sign-in and IM/Presence will work, just not Live Meeting. In this example the internal FQDN was simply duplicated into the external field. You could probably put any string in there, valid or not. Just as long as it is NOT blank.

External Deployment

As with anything in OCS, the external user access is where it can get tricky. Because this specific client was licensed for only Standard Edition a single consolidated Edge server was deployed, even though the A/V roles will not be utilized. This was done for two reasons, (1) licensing, and (2) future expansion. If they want to later open up external Communicator access and support features like Desktop Sharing, even though A/V sessions would still not be officially supported, the A/V functionality would need to be in place to get Desktop Sharing to work between internal and external clients. This point is worth reiterating. Desktop Sharing works via media communications.

The R2 Technical Reference details the Desktop Sharing Architecture explains that because the RDP sessions inherently run into the same challenges as media communications Microsoft decided to use A/V functionality in OCS, which already solved the previous issue. So basically Desktop Sharing is an RDP (Remote Desktop Protocol) session over SRTP (Secure Real-Time Protocol). The main difference is that Desktop Sharing uses TCP while standard media typically uses UDP, but the ports are the same.

But now back to our scenario; we only want Live Meeting supported externally, no audio, video, Communicator sign-in, and thus no Desktop Sharing. The reason I point this out is that when testing a deployment like this it would be a mistake to use Desktop Sharing to validate connectivity when it works completely different then Web Conferencing does.

First off, with any Edge deployment the firewall rules are most important. Let us assume a best practice deployment with the following IP subnetworks:

And here are the IP addresses and FQDNs to be used throughout this article:

Location	Interface	Role	IP Address	FQDN
Perimeter	External	Access Edge	103.207.10.10	sip.domain.com
Perimeter	External	Web Conferencing	103.207.10.11	webconf.domain.com
Perimeter	External	A/V Conferencing	103.207.10.12	av.domain.com
Perimeter	Internal	Edge Private Interface	10.1.1.100	edgeserver.dmz.local
Internal		OCS Front-End Server	172.16.1.111	ocspool.domain.local

It is important to point out here that the Access Edge FQDN has a specific requirement depending on if SRV records are used/supported and if anonymous access is desired for external Live Meeting clients.

If the _sip._tls.domain.com SRV record is published externally, then the Access Edge FQDN it points to can be named anything you want (within the same domain name). It is still best practice to use sip.domain.com but it does not have to be.
If SRV records are not supported by your external DNS server, then the Access Edge FQDN must be either sip.domain.com or sipexternal.domain.com.

This requirement is related to supporting Live Meeting connections from anonymous users which are not OCS-enabled users in your organization. If only corporate users need to use Live Meeting externally, then you can still use any FQDN you like and then Manual Configuration must be set on the workstation so that the OC/LM clients can locate the Access Edge server. But any third-party that wishes to join a hosted Live Meeting can only be invited via the meet:sip: URL that is typically sent in an email.

This URL includes the SIP domain name of the meeting scheduler:

meet:sip:jschertz@domain.com;gruu;opaque=app:conf:focus:id:3e068dc431be4509d1c3bb7…

Participating Live Meeting clients will perform an initial SRV lookup against domain.com for the Access Edge FQDN, followed by a fallback A record lookup. Only the default sip, sipexternal, and sipinternal A records are checked for, so you can see here that having an Access Edge FQDN of ocs.domain.com without an SRV record pointing to it is not sufficient to support Automatic Lookup. This behavior is the same for both the Office Communicator and Live Meeting clients. Once the client successfully connects to the Access Edge role, whether or not any authentication is happening (OCS user vs. Anonymous user) the Web Conferencing FQDN is passed to the client in-band (e.g. webconf.domain.com).

Now on to the fun stuff. I have chopped down the Microsoft diagram to include only the communications we need to support external Live Meeting clients. The two inbound rules (4,6) from the Internet are pointing to the separate IP addresses for the Access Edge and Web Conferencing Edge. The internal communications (5,7) are all happening between the internal Front-End server and the perimeter Edge server.

Firewall Policy Rules:

Rule	Firewall	Direction	Source Port	Source IP	Destination Port	Destination IP	Description
4	External	Inbound	Any	Any	443	103.207.10.10	Live Meeting sign-in and SIP signaling
6	External	Inbound	Any	Any	443	103.207.10.11	Live Meeting content sharing
5	Internal	Outbound	Any	172.16.1.111	5061	10.1.1.100	Communications from Front-End Server to Edge
5	Internal	Inbound	Any	10.1.1.100	5061	172.16.1.111	Communications from Edge to Front-End Server
7	Internal	Outbound	Any	172.16.1.111	8057	10.1.1.100	Live Meeting content sharing

Since the A/V Edge role is deployed as part of a consolidated Standard Edition server, it must be configured during setup or the wizard will not advance. Clearly there will be no external access to the A/V Edge and Authentication roles, so an internally-issued certificate will be fine here as the Access Edge and Web Conferencing roles would get third-party certificates (Entrust, Digicert, etc). The nice thing about this configuration is if a later pilot rollout of external A/V is requested all that is needed is a certificate and some firewall changes and everything is already set to go.

Testing

Once all the rules are setup and the Edge server is deployed and configured each can be tested via telnet. From the internal Front-End server you should be able to telnet to both ports 5061 and 8057 on the Edge’s internal IP. You can also perform the same test from the Edge server to 5061 on the internal Front-End server. Additionally any public host should be able to telnet to 443 on either the sip or webconf IP addresses to verify the external rules as well.

Connecting directly to the port via telnet will both confirm that the firewall rule is correctly defined and that the service is active and listening.

A failed connection to any of the ports would be pretty clear:

C:\>telnet 10.1.1.100 5061

But a successful connection to either ports 5061 and 443 would not be as obvious as nothing appears to happen. The blinking cursor indicates a connection to the port; there is just no interaction:

C:\>telnet 10.1.1.100 5061

Meanwhile a successful connection to the PSOM service on port 8057 at the Edge internal interface would at least spit out a few characters:

C:\>telnet 10.1.1.100 8057

Internal Configuration

First verify if the External Web Farm FQDN needs to be populated or updated by checking the current value, which can be viewed (but not modified) from the OCS Management Console as shown below. If the External URL value needs to updated then follow the instructions in Appendix E of the OCS documentation.

Pool Properties > Web Components Properties > Address Book tab

By default web conferencing is not enabled in a fresh installation. There are a couple ways to turn it on, depending on if you want everyone in the organization to have the same features and permissions, or if you need to have separate groups of users with different policies.

The simplest approach is to just edit the Default Policy and enable Web conferencing and any other desired options.

Alternatively you can elect to choose from different set policies for each SIP-enabled user account. The built-in policies offer different levels of permissions but can each be customized, as well as removed or replaced by other new policies.

External Configuration

Now even though external Communicator support is not part of this deployment, user accounts must still be SIP-enabled in order to schedule and initiate Live Meeting sessions and thus invite attendees. If Communicator must still be blocked, then limiting the ability to install the Communicator application on corporate systems is one approach. Another would be configuring global policy settings to limit the types of communications (block IM, peer-to-peer audio, etc) in the client. Make sure to follow the standard post Edge deployment configuration by adding the Edge server settings in the various Global and Pool level properties

For this deployment all OCS features would be used internally, so only external user login was undesired. But In order to first allow access to Live Meeting externally the Edge Server properties must be configured to allow any external access. There is no way to allow for external access to Web Conferencing without also allowing external access, since the Live Meeting client must first connect to the Access Edge service to initiate a conferencing session.

Edge Server Properties > Access Methods

The next step is to enable rights on each user account for remote user access. This inherently also grants the user the ability to sign-in to Communicator remotely; these rights cannot be separated. So if only anonymous access to Live Meeting sessions is desired for all remote users, whether they are corporate employees or a third-party, then this step can be skipped. But since most deployments would want corporate users to be able to sign-in as themselves to conferences regardless of their location that permission must be enabled on each account.

User Account Properties > Communications Additional Options:

Category: Office Communications Server

Published: 6/3/2009 3:44 PM

Categories: Office Communications Server

A/V Edge Authentication Connection Errors

Jeff Schertz — Mon, 22 Jun 2009 13:11:31 GMT

Body:

Just a quick note regarding an error I recently ran across. A client was experiencing problems with Dial-In Conferencing after a recent deployment and during troubleshooting the issues I ran across this pair of errors in the Front-End server’s OCS event log:

OCS Audio-Video Conferencing Server
Event ID 32018
“The Audio-Video Conferencing Server encountered an error when requesting credentials from the A/V Edge Authentication Service.”

OCS Protocol Stack
Event ID 14502
”A significant number of connection failures have occurred with remote server…”
8007274D
80072746

The IP address of the the ‘remote server’ described in ID 14502 was actually the IP address on the Edge server’s internal interface. So after checking the the common reasons for server-to-server communications issues (filtered ports on firewalls, incorrect or missing DNS entries, or invalid certificates) everything appeared to check out. All other features were working, as internal to external audio and video communications were tested multiple times in addition to Live Meeting and Desktop Sharing.

The A/V Authentication service was correctly configured on the Edge Server’s Interfaces tab on the default port of 5062, and from the Front-End server I was able to telnet directly to that port. Hmmmm…

Next step was to check the internal configuration and make sure that the Front-End services were attempting to go to the right place.

Bingo! The A/V Edge Servers entry under the Global Properties > Edge Servers tab had the correct FQDN but was mistakenly configured to use 443 instead of 5062, where the A/V Auth service was actually listening on the Edge’s internal IP.

Simple enough, just change it, right? That would be too easy. You can’t edit the current entry. And attempts to directly resolve it will be thwarted by one of two errors messages depending on if you attempt to delete the current entry and replace it with a new one, or simply try to add a second entry for the same FQDN with a different port value.

“The A/V Edge Server internal FQDN and A/V authentication port is currently assigned to a pool or server. Please check the Status Pane. Removing this entry may result in the failure of users to exchange media.”

“Trusted entry breaks the FQDN, Port or Version uniqueness constraint.”

Resolution

At this point we’ll need to un-assign the current value from a couple places in the OCS configuration so that the invalid entry can be removed.

First go to the Pool Properties under the Pool object and change the A/V Authentication Service to (None).

And then from the Mediation Server Properties also change the A/V Edge Server setting to (None).

Give Active Directory some time to replicate these configuration changes around, and we can go back and remove the original entry and replace it with the correct port number.

Revisit the Global Properties on the OCS Forest object and delete the existing A/V Edge Server entry with the invalid port listed.
Create a new entry with the correct values. (Depending on the time elapsed between now and the previous steps you may receive another “Trusted entry breaks FQDN…constraint” warning but it can be ignored at this point.)

After restarting the Front-End services those two errors should stop appearing in the event log and Front-End to A/V Authentication communications should now be working.

Category: Office Communications Server

Published: 6/22/2009 8:11 AM

Categories: Office Communications Server

OCS Dial-In Conferencing: Unable to Join Conference Calls

Jeff Schertz — Thu, 25 Jun 2009 18:51:27 GMT

Body:

In keeping with this month’s apparent theme of troubleshooting Live Meeting and Audio Conferencing problems for external users, I ran into yet another weird one. This time we have a pretty basic Office Communications Server 2007 R2 deployment with Enterprise Voice using a NET VX1200 media gateway with Cisco Call Manager 4.1. All OCS features are deployed and working with best practices followed for nearly every piece of the puzzle; no cutting any corners. The latest round of OCS patches have been applied and everything is looking good.

That was until I started testing Dial-In Conferencing. I found that OCS users were able successfully join audio conferences using either a dynamic Conference ID from a scheduled meeting or their own personal Conference IDs, but only when they joined from the link within an email/meeting.

But if an OCS user attempted to manually dial the Conferencing Attendant number, or if a PBX or PSTN phone called directly into the same number, they were unable to join the meeting. The Conferencing Attendant would accept the given ID as valid and then attempt to transfer the call into the meeting, at which point would fail as the attendant responded with:

"Sorry, but i can't seem to connect you to your conference right now. Please try your call again later. Goodbye."

The caller would then be immediately disconnected. I did find out that after restarting the server the very first attempt to join any conference would actually work, but then all subsequent attempts would fail regardless of where the call was dialed from. Whether other OCS users were already connected to the meeting (using the link) or no one was connected, inbound callers would always fail. And it didn't matter if callers attempted to join anonymously (via meeting passcode) or authenticated (using their personal PIN).

Something was definitely wrong; I triple-checked the OCS configuration and event logs but nothing was out-of-place. So I walked through each of these three scenarios with debug logging enabled:

Test Scenarios
- Joined OCS User A to scheduled Audio conference using link in meeting invite = Success
- Joined OCS User B to conference by manually dialing '6789' in the Search bar in OC = Failure
- Joined PSTN Caller using external DID '+13125556789' = Failure

Recorded trace data on FE server for following components:
- AcpMcu
- AvMcu
- CAAServer
- CASServer
- S4
- SIPStack

After going through the AvMcu log with Microsoft PSS the following error was located at the time when callers were unable to join the meeting and were disconnected:

TL_ERROR(TF_COMPONENT) [3]117C.1554::06/11/2009-16:00:38.162.0003a54f (AvMcu,UserMediaManager.CreateEndpointAndStreamsCallback:usermedia.cs(821))( 00000000027630E1 )[UserMediaManager]{sip:a4eecd6e49dd404488af679e8e8a1a29@anonymous.invalid} MP CreateEndpointAndStreams exception. System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.Rtc.Internal.Sip.TLSListener.SignString(String signString, String& hashAlg, String& signAlg)

The highlighted section in the line above caught our attention as I had already seen a previous issue earlier that week at the same client which ended up being related to their internal certificate. They had deployed an internal Windows 2008 Enterprise CA but had elevated the signing algorithm to SHA2 256, above the default SHA1 value. But the affected server in that case was the only Windows Server 2003 system in the domain, all others (including the OCS servers) were running on Server 2008 which natively supports that higher level. But because the failure seemed to be internal as the conference service couldn’t handling moving calls between it;s own services (from the lobby to a meeting) I had a hunch it might still be related to the hash level.

Here we can see in the details of the certificate that the Signature Algorithm is indeed sha256RSA:

A quick verification of the General Properties on the Windows 2008 Enterprise Certification Authority show that the Hash algorithm used on the root CA is also using sha256:

Since the internal CA here is only configured to sign certificates using SHA2 we went out to RapidSSL to request a thirty-day free trial certificate to temporarily use on the Front-End Server. Here we can see that the certificate is using the more common SHA1 for it’s Signature Algorithm:

After applying the new certificate to OCS and selecting it in IIS I rebooted the server for good measure. Initially the problem appeared to be resolved as I was able to dial directly into an audio conference from an internal PBX phone, followed by a PSTN phone. The second caller was actually added to the conference successfully (yeay!) but in doing so the first caller was immediately booted out of the room (boo!). And when I dialed in from a third phone, you guessed it, the second caller was promptly disconnected.

I looked at the OCS Event Log on the Front-End server showed a whole bunch of new error messages that had not been there before, describing lots of MCU errors, which would explain the failure to join additional parties. Details on the error messages can be found in this TechNet blog.

Turns out that the new certificate was (partially) to blame as it’s Issuing CA’s certificate is not configured by default in Windows Server in a way that is supported by OCS. By checking the new certificate's path we see that the Equifax Secure Certificate Authority is the issuer used by the RapidSSL free certificate:

By locating that certificate in the Third-Party Root Certification Authorities\Certificates folder in the Local Computer store and viewing the properties we can see that by default the certificate is only enable for a specific sub-set of purposes. To resolve the MCU errors in OCS it needed to be enabled for all purposes.

Once that change was made and the services are restarted, the MCU event log errors stopped appearing and all parties were all to join Dial-In Audio Conferences regardless of where and how they connected to the service. This proved that the previous certificate was the culprit and that the higher level of encryption on the signature was causing the validation problems.

Microsoft is currently looking into this and have successfully reproduced the issue in a lab. Once their debugging is completed I’ll update this blog posting with details on whether a hotfix or KB article is released in response.

Update

I’ve received word back from Microsoft that the issue has been fully replicated and tested in both Standard and Enterprise Edition, and certificates issued with a Signature Algorithm of MD5 or SHA2 cannot be supported for OCS R2. Only certificates using SHA1 with up to a 4096 bit key length will operate correctly. Support for SHA2 and MD5 is being considered for the next release of OCS.

Category: Office Communications Server

Published: 6/25/2009 1:51 PM

Categories: Office Communications Server

OCS R2 Edge Topologies Explained

Jeff Schertz — Thu, 02 Jul 2009 16:02:51 GMT

Body:

Byron Spurlock has a blog article that briefly talks about the different topologies for Edge servers in R2 but I wanted to go into a little more detail and highlight a few seemingly small, but important changes introduced in R2 that sort of flew in under the radar as all the other neat features in R2 took center-stage.

Pre-R2 Topologies

Firstly, anyone versed in OCS should know that when deploying an Edge Server you could select what roles you wanted to install, with a few limitations. The following table shows the different Edge Server configurations supported by OCS 2007 pre-R2 as described in the Edge Server Deployment Guide.

Topology	Description
Consolidated Edge Topology	Access Edge Server, Web Conferencing Edge Server, and A/V Edge Server are collocated on a single computer.
Single-Site Edge Topology	Access Edge Server and Web Conferencing Edge Server are collocated. The A/V Edge Server is on a separate computer.
Scaled Single-Site Edge Topology	Computers with a Web Conferencing and Access Edge Server role collocated on them are load balanced. Two or more A/V Edge Servers are each installed on separate computers and load balanced.
Multiple Site with a Remote Site Edge Topology	Primary Site: Computers with a Web Conferencing and Access Edge Server role collocated on them are load balanced. Two or more A/V Edge Servers are each installed on separate computers and load balanced. Each Remote Site: One or more Web Conferencing Edge Server are installed on a dedicated computer. The A/V Edge Server is installed on a dedicated computer.

The different Edge roles were allowed to be installed on different physical hardware, resulting in many different (and potentially confusing) scenarios. Basically you could have (1) a dedicated server for each role, (2) separate servers with the Access Edge and Web Conferencing together with another server hosting the A/V Conferencing role, or (3) all three Edge roles on the same system. Then you could install multiple arrays of these different scenarios. Lost yet? Yeah, me too.

Microsoft acknowledged that this flexible, albeit overly complex set of configurations was rarely used in practice. Nearly every enterprise level deployment we performed prior to R2 simply used one or more Consolidated Edge Server. The requirement to break up SIP and Media traffic on dedicated systems was never important enough to warrant separating all those roles out as usually physical space, available IP addresses, and cost were the driving factors.

Enter Release 2

The supported Edge topologies for OCS 2007 R2 have been greatly simplified by changing one key requirement: Only Consolidated Edge Servers are supported. In fact, the deployment wizard (whether run from the Standard Edition or Enterprise Edition media) only allows for the installation of all components. There is no longer an option to choose which Edge role(s) to install on the server. Regarding support, the R2 documentation states the following:

Supported Topologies
Each Edge Server always runs all three Edge Server services: Access Edge service to validate external users and enable instant messaging (IM), Web Conferencing Edge service to enable external users to join on-premises meetings, and A/V Edge service to enable the sharing of audio and video with external users, and enable Desktop Sharing with external users.
You can configure one or more Edge Servers on your network, according to your performance needs. Three Edge Server topologies are supported: single consolidated edge topology, scaled consolidated edge topology, and multiple-site consolidated edge topology.

What is important to clarify is that all three different topologies still utilize Consolidated Edge Servers. By having all three Edge roles in a single server you simply add additional hosts to create and expand a pool of servers as bandwidth requirements increase. The previously supported Consolidated and Single-Site scenarios are affectively merged into the same scenario now, leaving just 3 unique topologies.

For example, here’s the diagram of the Scaled Consolidated Edge Topology that shows a pool of consolidated Edge Servers:

So the simple take-away is that with R2 forget what you know about previous Edge role collocation and just think that there is now only one type of Edge Server.

Multiple Access Edge Roles

Ok, so now you may be saying to yourself “I thought multiple Access Edge servers weren’t supported in a multi-site topology” and you’d be correct. If you are deploying multiple consolidated Edge Server in different sites that all support users for the same SIP domain (read: single DNS SRV record for Automatic Configuration) then the primary site’s Access Edge Server roles should be configured to handle external client login. The other server’s Access Edge roles will still be deployed and configured with unique FQDNs, but they will not be used and basically sit idle. The remote site’s Edge server’s will handle Web Conferencing and A/V traffic though, which is considerable more bandwidth intensive the basis SIP traffic that the primary site handles.

A/V Edge with NAT

As Matt and others have previously discussed NAT works when used on the A/V Edge Role in R2, the different support statements throughout the documentation can be read in ways that might seem confusing.

The Security section makes a this statement:

If the edge server is a single consolidated edge server, Office Communications Server 2007 R2 allows the use of NAT for all three edge services.

The first time I read that I assumed (thinking back to what I knew was true with pre-R2 topologies) that it meant the NAT limitation hinged on the word ‘consolidated’ not realizing that the keyword was actually ‘single’.

Meanwhile the Operations portion of the R2 documentation has a clearer definition that better calls attention to the fact that a single server versus multiple servers is where the limitation on NAT stands.

To allow the external IP address to be translated from a public IP (NAT), select the External IP address is translated by NAT check box. This option is valid for a single A/V Edge service deployment. Multiple A/V Edge services that are deployed behind a load balancer do not support network address translation (NAT).

So, I hope this helps clear up any confusion people might have on the change in Edge topologies.

Category: Office Communications Server

Published: 7/2/2009 11:02 AM

Categories: Office Communications Server

Attachments: http://blogs.pointbridge.com/Blogs/schertz_jeff/Lists/Posts/Attachments/70/image_2_21A18FF5.png
http://blogs.pointbridge.com/Blogs/schertz_jeff/Lists/Posts/Attachments/70/image_thumb_21A18FF5.png

OCS Service Startup/Shutdown Order

Jeff Schertz — Tue, 04 Aug 2009 18:04:55 GMT

Body:

Typically when restarting services in Windows most people use the Services snap-in or the net start/stop commands, but the OCS Management console offers a simple way to stop and start services in a pre-defined order.

I investigated the behavior of this to learn what the preferred order or service dependencies may be (if at all) within OCS. Unlike Exchange Server, where a number of services are dependant on others on the local system, none of the core OCS services are dependant on other core services. So technically there does not appear to be a required order to stop and start services, but here’s what the console does.

Shutdown

OCS 2007 Standard Edition Front-End Server

Office Communications Server Front-End
Office Communications Server IM Conferencing
Office Communications Server Telephony Conferencing
Office Communications Server Monitoring Agent
Office Communications Server Web Conferencing
Office Communications Server Audio/Video Conferencing
Office Communications Server Application Sharing
Office Communications Server Response Group
Office Communications Server Conferencing Attendant
Office Communications Server Conferencing Announcement
Office Communications Server Outside Voice Control

The Office Communications Server Application Host service is not automatically stopped as part of this programmed sequence, but each of the four built-in OCS application services are. This is most likely incase additional custom application are deployed on the Front-End server which would rely on the Application Host running. When rebooting the server that service can be left to be stopped by the shutdown process, but if rebooting all OCS services manually for some testing it wouldn’t hurt to manually restart the Application Host if desired.

Startup

One might assume that when issuing the command to start all stopped services from the management console that the exact opposite behavior would be seen. But oddly enough it’s the same exact order during services startup. Other than the aforementioned Application services (which would be assumed to be still running since the console didn't issue a stop request to it) non of the OCS services have a configured dependency on any other OCS services. There are dependencies on the WMI service, but since there are no inter-dependencies among the OCS services they can really be started/stopped in generally any order. But following the order that the management console was programmed to do is best practice.

And although the console-based Startup routine does not issue a start control, because of the set dependency when the Application Sharing service is started the Application Host service will automatically be started by the Windows Server host.

Category: Office Communications Server

Published: 8/4/2009 1:04 PM

Categories: Office Communications Server

Attachments: http://blogs.pointbridge.com/Blogs/schertz_jeff/Lists/Posts/Attachments/71/image_4_28F1C1C7.png
http://blogs.pointbridge.com/Blogs/schertz_jeff/Lists/Posts/Attachments/71/image_6_28F1C1C7.png
http://blogs.pointbridge.com/Blogs/schertz_jeff/Lists/Posts/Attachments/71/image_thumb_1_28F1C1C7.png
http://blogs.pointbridge.com/Blogs/schertz_jeff/Lists/Posts/Attachments/71/image_thumb_2_28F1C1C7.png

Managing Certification Authority Certificates for OCS

Jeff Schertz — Wed, 05 Aug 2009 15:17:28 GMT

Body:

Typically in a basic deployment there are times when Windows workstations and servers which are not members of the internal Active Directory domain need to communicate with OCS servers. This could be attempting to sign-in to Office Communicator installed on a test workstation on the internal corporate network, as well as a perimeter-network server (like ISA or and OCS Edge server) attempting an MTLS connection to an internal OCS server. This also applies to external workstations trying to sign-in to an Access Edge service which has been configured with a private internal certificate instead of a publicly-trusted third-party cert.

By default, when a Windows computer (Workstation or Server OS) is a member of an Active Directory domain which has an internal Enterprise Certificate Authority installed in it that computer automatically trusts that certificate authority. If a multi-tier CA deployment exists, then the client will have already imported all Root and Subordinate CA certificates.

This topic has been covered many different times for other PKI-leveraging products, and is discussed in multiple places throughout the OCS product documentation. But it’s a pretty common stumbling-block (seen in the TechNet support forums very often) for users and administrators who are new to the idea of using certificates. So here’s a detailed walkthrough to show how to export certificates from certificate authorities into non-domain-joined workstations and servers.

Certificates Console

By default Windows does not include a published Administrative Tool for accessing the certificates store, you must first create the console by adding an MMC snap-in. This process is the same for all current Windows operating system types and versions, and lets you view and manage the certificates on the local computer. It’s important to note that the Computer Account (and not the logged on user’s account) is where certificates must be managed for all these processes. Putting certificates in the wrong stores and folders will prevent successful communications between hosts.

From the Run command enter mmc.exe
From the File menu select Add/Remove Snap In…
Add the Certificates snap-in
- When prompted to select what store, select Computer Account
- When prompted to select what computer to manage, select Local Computer

Validating a Domain Member’s Certificates

To first see what the expected end-result would look like, and to understand why domain-joined computers can communicate with the OCS servers without issues let’s look at the trusted certificates currently setup on a domain workstation. Using the previous steps, open the Certificates console on any domain-joined computer.

Expand the tree out to the Trusted Root Certification Authorities\Certificates folder and locate the root certificate. If you aren’t sure of what the name is it can help to sort the Intended Purposes column and look at the few certificates listed with <All> purposes. In the screenshot below we can see my lab’s Root Certificate Authority’s certificate is stored here. Unless some custom Group Policy change were made to prohibit certificate downloads to domain members, all domain computers should have the internal Enterprise CA root certificate stored in this location.

If there is more than one tier of Certificate Authorities deployed in the domain, then additional subordinate (Policy and/or Issuing) CAs would be found (along with a second instance of the Root CA’s certificate) in the Intermediate Certification Authorities\Certificates folder. This screenshot shows both my Root (SchertzLabRootCA) and Issuing CA (SchertzLabIssuingCA) certificates.

This is indicative of a more secure CA deployment utilizing and offline Root CA with an online issuing, subordinate CA. It’s important to identify which type (thus how many certificates) is used in your environment so that all are exported and imported correctly. If only the Root CA certificate is imported into a workgroup computer and not the Issuing CA cert (which most likely issued the certificates to the OCS servers) then communications will fail as the chain of trust will not be complete.

Failed Sign-In From Workgroup Computer

When attempting to sign-in to Office Communicator from a computer that doesn’t trust the CA that issued certificates to the OCS server, it’s pretty clear that it won’t work as sign-in immedataly fails with the following error: “There was a problem verifying the certificate from the server. Please contact your administrator.”

A quick look at the Application Event Log on the local computer shows a bit more details as to what happened:

Event Type:     Error
Event Source:   Communicator
Event ID:       5
Description:
Communicator could not connect securely to server pool1.schertz.lab because the certificate presented by the server was not trusted due to validation error 0x80090325. The issuing certificate authority (CA) for the server's certificate may not be locally trusted by the client, the certificate may be revoked, or the certificate may have expired.

Since the error description mentions a few different potential causes, let’s use the LCSerror.exe command from the OCS Resource Kit tools to lookup that specific error code for a more definitive description.

c:\>lcserror 0x80090325
0x80090325 -> (SEC_E_UNTRUSTED_ROOT) (kernel32.dll) The certificate chain was issued by an authority that is not trusted.

So based on those results, we have confirmed that the root cause is the lack of any trusted CA certificates on the local computer.

Exporting Certificates

Microsoft has a TechNet article (KB555252) that covers how to export the certificate from the Root CA, but the directions assume that you have console access to the Root CA. Except for testing environment, most users and even Administrators should neither have access nor be able to get to the Root CA as protecting the private key of that system is imperative to a solid PKI infrastructure. It is also unnecessary to access the CAs directly to get to their certificates, they are already installed on any domain-member. And since the private key is not needed (nor desired, you should never export the Root CA’s private key onto a less-secure server) there is even less of a reason to do it the way shown in that article.

So the simplest route is to just jump on the OCS Front-End server to export CA certificates. In order to validate that all certificates are exported, let’s look at the Certification Path on the certificate issued to the OCs services.

Open up the Certificates console using the same instructions as shown in the beginning of this article.
Expand the Personal\Certificates folder and locate the certificate assigned to the OCS Front-End services.
Open the certificate (or Open from the right-click menu; not Properties).
Select the Certification Path tab.

Here I’ve included screenshots of both potential scenarios, a single-tier CA deployment, and a multi-tier CA deployment.

Start with exporting the root certificate for either scenario:

Highlight the top-level root certificate and click the View Certificate button.
Select the Details tab and then click Copy to File.
From the Certificate Export Wizard select DER Encoded binary X.509 (.CER)
Save the file to local drive (e,g, c:\RootCert.cer)

For the second example where the OCS certificate was issued by a subordinate CA we’ll need to also export the Issuing certificate. Follow the exact same steps as shown above for the next certificate down the chain. If there a even more level’s then make sure all certificates in the chain are exported to a .CER file.

Importing Certificates

Now that we have the certificate files exported as that is left to do is move them over to the desired computer and import them into the proper location. If there is only a single Root CA then that single file is imported into just the Trusted Root Certification Authorities folder, but if there are multiple CA certificates then in addition to placing the Root there, all certificates (root and all subordinates) in the chain are placed into the Intermediate Certification Authorities folder as well.

Importing the Root CA certificate:

Copy the RootCert.cer file to over to the workgroup computer.
Open the Certificates console as shown in the beginning of this article.
Expand and highlight the Trusted Root Certification Authorities\Certificates folder.
From the Action menu select All Tasks > Import.
In the Certificate Import Wizard:

Select the previously exported file (RootCert.cer).
The Certificate Store should automatically display the location you started the Import wizard from. Make sure that it is the "Trusted Root Certification Authorities” and finish the wizard.

Importing Subordinate CA certificates:

If there are any remaining subordinate certification authority certificates to import, follow the same steps as above for each certificate (including the root) but instead import them all into the Intermediate Certification Authorities store.

The desired configuration would include the Root CA certificate in both the Root and Intermediate stores, with all other subordinate certificates in only the Intermediate store:

Trusted Root Certification Authorities

Root CA certificate

Intermediate Certification Authorities

Root CA certificate
Policy CA certificate
Issuing CA certificate
Issuing CA certificate
etc…

At this point Office Communicator should be able to sign-in without the previous 0x80090325 error. The same steps can be used to configure the certificate chain for an OCS Edge server or to setup Federation with a peer who isn’t using public certificates on their Access Edge proxy. Basically any time two hosts need to communicate securely by negotiating a certificate-based network connection, if both parties do not already trust each other’s certificate issuers.

Category: Office Communications Server

Published: 8/5/2009 10:17 AM

Categories: Office Communications Server

OCS Services Hang on Startup

Jeff Schertz — Thu, 13 Aug 2009 16:04:56 GMT

Body:

In a recent deployment OCS 2007 R2 Enterprise Edition was deployed to a physical server running Windows Server 2008 that began to exhibit problems immediately after the first reboot. Basically the server failed to respond to network traffic and was unreachable via RDP or other previously listening services after restarting.

Upon connecting to the console locally the server had apparently dropped off the network, as indicated by the system tray Network icon displaying as disabled.

After checking the physical connections and verifying there was no IP address conflict a number of hardware-related tests were run. Eventually we found that if the OCS services were disabled then the server would boot normally with networking enabled. Checking the logs showed that all OCS services appeared to hang on startup for 10-15 minutes, after which they would all start and both OCS and Windows itself functioned normally. The server appeared back on the network and all looked fine, until the next reboot. If each OCS service was disabled then the server would boot-up normally and respond to network traffic immediately. The latest round of OCS hotfixes were applied to the server but there was no change in behavior.

A contact in the OCS Senior Support team then sent me the following details as the issue has been seen before in other Server 2008 OCS Front-End deployments, but has not yet been reproduced under testing. It’s so far unknown if the there is a conflict between Server 2008 and the specific hardware used in this scenario, or if that is entirely unrelated.

Resolution

The workaround instructions we received from the Microsoft Product Support team was to configure a dependency on the WMI Performance Adapter service.

Set the Startup Type of the WMI Performance Adapter service (wmiApSrv.exe) to Automatic

Configure the OCS Front-End service (RtcSrv.exe) to be dependant on the WMI Performance Adapter service

The ‘sc config’ command can be used to modify the DependOnService value. Note that by default the Front-End service is already dependant on the Windows Management Instrumentation (WinMgmt) and CNG Key isolation (KeyIso) services. Because this command overwrites the current value both the existing and new entries must be supplied. To verify the current configuration is the same as this example, check the Dependencies tab on the Front-End server before making any changes.

Then issue the following command to configure the new dependency. Add any additional dependant services to the command below to retain any other services that might already be customized.

c:\>sc config rtcsrv depend= WinMgmt/KeyIso/WmiApsrv
[SC] ChangeServiceConfig SUCCESS

To double-check the new service dependency the registry value can be viewed here:

HKEY_LOCAL_MACHINE\SYSTEM\ControlControlSet\Services\RtcSrv\DependOnService

Restart the server and validate that all OCS services start correctly, and in a timing manner with no adverse impacts to the host’s Network connection

If this does not resolve the original issue (as was the case with this specific deployment) then it’s further recommended to set a delayed startup on all OCS services except for the Front-End service.

Leave the Startup Type of all Office Communications Server Front-End service set to Automatic
Configure the Startup Type of all other Office Communications Server services to Automatic (Delayed Start)

This last step resolved the startup issues on the Front-End server by allowing Windows to complete bootup and register with the network before starting up additional OCS services. this is considered more of a workaround as the root-cause was not yet identified.

Category: Office Communications Server

Published: 8/13/2009 11:04 AM

Categories: Office Communications Server

OCS R2 CWA Single Certificate Configuration

Jeff Schertz — Wed, 19 Aug 2009 12:35:42 GMT

Body:

Although I find it best practice to deploy two separate certificates on an OCS R2 Communicator Web Access server, there are times when using a single certificate for both server-based MTLS and client-based SSL communications are the best approach, mainly cost if an internal CA is unavailable and all certificates are being purchased. The problem is that getting a single certificate to work for both roles will typically fail if you follow the current guidelines.

The official OCS R2 documentation for Preparing Certificates for Communicator Web Access currently states the following:

“Although Communicator Web Access uses two different protocols you can typically get by with installing a single certificate: in most cases the same certificate can be used both for MTLS and SSL. (The MTLS certificate is assigned when you activate Communicator Web Access, while the SSL certificate is assigned each time you create a virtual server). If you have just one Communicator Web Access server you can use a single certificate as long as that certificate meets the following criteria”

Subject Name

Matches the URL of the Communicator Web Access site. For example, if the URL is https://im.contoso.com then the certificate should have im.contoso.com as subject name.

Subject Alternative Name
(SAN)

Includes the following:

The URL of the Communicator Web Access site.
The as URL.
The download URL.
The fully qualified domain name (FQDN) of the Communicator Web Access server

The problem is that this statement is unfortunately incorrect. The remaining half of that page is correct in terms of the certificate configuration required for using two separate certificates for MTLS and SSL communications, but if the directions above are followed to create a single certificate it will not work.

Validation

Assuming we have a newly deployed CWA server called cwaserver.contoso.com I’ll request a new certificate using the following fields, matching the documented requirements. (Note that the server’s FQDN doesn't necessarily have to be in the same domain as the published web address. The documentation assumes the same domain namespace, but the server FQDN could just as easily be in nwtraders.local, for example. This is common when the internal Active Directory namespace is different than a company’s public domain name which is used for SMTP and SIP services.)

Subject	CN = im.contoso.com
Subject Alternative Name	DNS Name = im.contoso.com DNS Name = download.im.contoso.com DNS Name = as.im.contoso.com DNS Name = cwaserver.contoso.com

When the Activate Communicator Web Access wizard is run and this certificate is selected, it will fail with the error “The subject of the certificate you selected doesn’t match the current computer’s FQDN.”

This is because the MTLS server-to-server communications in OCS are established by resolving the server’s hostname and if the certificate’s Subject Name is something other than the server name then communications will fail. The wizard looks for this requirement and blocks to assignment of a certificate that will not meet that requirement. The last section on the same page of the OCS documentation reflects that requirement in the MTLS certificate configuration example:

“The MTLS certificate should list the full qualified domain name (FQDN) of the Communications Web Access computer in the subject name of the certificate. If the fully qualified domain name (FQDN) of that computer is cwaserver.contoso.com then the MTLS certificate should include the following information (with no subject alternative name required)”

Subject Name

cwaserver.contoso.com

Resolution

So if you have not figured it out by now, the correct configuration is to use the server’s FQDN in the Subject Name of the single certificate and then populate the SAN field with all names. This will meet the Activation wizard’s requirement for assigning an MTLS certificate, and the published URL in SAN field will suffice for SSL communications.

Subject	CN = cwaserver.contoso.com
Subject Alternative Name	DNS Name = im.contoso.com DNS Name = download.im.contoso.com DNS Name = as.im.contoso.com DNS Name = cwaserver.contoso.com

As I understand it, this portion of the deployment documentation is under review by the product team and I hope to see it corrected in the near future. I’ll update this blog when that happens to reflect any changes.

Category: Office Communications Server

Published: 8/19/2009 7:35 AM

Categories: Office Communications Server

Attachments: http://blogs.pointbridge.com/Blogs/schertz_jeff/Lists/Posts/Attachments/75/clip_image002_2_2FCF7F45.jpg
http://blogs.pointbridge.com/Blogs/schertz_jeff/Lists/Posts/Attachments/75/clip_image002_thumb_2FCF7F45.jpg

OCS Deployment Log Tips

Jeff Schertz — Tue, 25 Aug 2009 19:14:29 GMT

Body:

These are some pretty basic notes, but worth calling out for the benefit of users new to the OCS Deployment Wizard. Troubleshooting deployment issues is pretty common and the logs are the best place to start from.

During the various setup wizards in OCS each step typically concludes with a window reporting either successful or failed results. It’s recommended to review each log even if the wizard completes successfully as there could be one or more warnings worth looking into. Some warnings can be ignored as certain checks may not apply to the specific deployment at the time.

If the checkbox isn’t marked or the window closed accidentally, no problem. The files are all saved by default in the system temporary directory (%TEMP%).

By default Internet Explorer will not allow the active content to run that is embedded in the deployment logs. The Collapse/Expand controls will not work, making the log appear to be a bit light on details. In order to access the content of the log the Allow BLocked Content option must be chosen from the right-click menu on the alert message.

But this gets annoying when viewing multiple logs during deployment and/or troubleshooting, so there is a simple setting in the Internet Explorer Advanced properties that can remove that restriction. Simple enable the “Allow active content to run in files on My Computer” setting and then restart Internet Explorer. I typically flip this setting on the OCS server during deployment, but then revert back to the default when done.

When viewing short logs it’s easier to simply hit the Expand All option in the upper-right hand corner and then scroll through the displayed contents.

But when tracking down errors in large, detailed logs it’s usually easier to skip that and only expand the individual Actions displaying the error result. This helps to quickly drill down to the desired section instead of just scrolling through page after page.

Category: Office Communications Server

Published: 8/25/2009 2:14 PM

Categories: Office Communications Server

Attachments: http://blogs.pointbridge.com/Blogs/schertz_jeff/Lists/Posts/Attachments/76/image_12_4CE9C56A.png
http://blogs.pointbridge.com/Blogs/schertz_jeff/Lists/Posts/Attachments/76/image_2_4CE9C56A.png
http://blogs.pointbridge.com/Blogs/schertz_jeff/Lists/Posts/Attachments/76/image_6_4CE9C56A.png
http://blogs.pointbridge.com/Blogs/schertz_jeff/Lists/Posts/Attachments/76/image_8_4CE9C56A.png
http://blogs.pointbridge.com/Blogs/schertz_jeff/Lists/Posts/Attachments/76/image_thumb_2_4CE9C56A.png
http://blogs.pointbridge.com/Blogs/schertz_jeff/Lists/Posts/Attachments/76/image_thumb_3_4CE9C56A.png
http://blogs.pointbridge.com/Blogs/schertz_jeff/Lists/Posts/Attachments/76/image_thumb_4CE9C56A.png
http://blogs.pointbridge.com/Blogs/schertz_jeff/Lists/Posts/Attachments/76/image_thumb_5_4CE9C56A.png

OCS Certificate Deployment White Paper

Jeff Schertz — Fri, 28 Aug 2009 21:19:43 GMT

Body:

Microsoft has just released a new white paper on using certificates with Office Communications Server. Although entitled “OCS 2007 R2 Deploying Certificates” it actually covers both 2007 and 2007 R2 versions of OCS.

This is a very comprehensive document (just short of 100 pages) that covers everything from basic requirements down to specific scenarios like sample LCSCMD commands for requesting certificates for a reverse proxy. A number of the common problems and misunderstood areas have been addresses in much more detail and the original planning and deployment documents, so I highly recommend reading through this document. I learned a few things myself in reading the initial drafts that weren’t covered by any existing documentation.

I’ve known about this document for some time as I and other MVPs have been reviewing and offering input on the various revisions for some time, but can only now inform others as the final work has been released publicly. Thanks to Rick Kingslan for allowing a number of people to review and add content that consultants out in the field felt was important to add. I know I’ll soon be pointing a lot of TechNet forum users to this document link.

The white paper can be downloaded directly from the link below:

Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2

http://go.microsoft.com/fwlink/?LinkId=163083

(If the above link doesn’t work then head over to the master Microsoft Office Communications Server 2007 R2 Documentation page and download the document named OCS 2007 R2 Deploying Certificates.doc from the ‘Files in this Download’ section.)

Category: Office Communications Server

Published: 8/28/2009 4:19 PM

Categories: Office Communications Server

OCS Edge on Server 2008 – The Strong Host Model

Jeff Schertz — Thu, 17 Sep 2009 14:18:48 GMT

Body:

The typical OCS deployment these days is using Windows Server 2008 instead of Server 2003 for the host OS now since R2 and Server 2008 have been out for some time, so a certain issue has begun to pop up in some deployments. Basically, if an R2 Edge server is deployed on Server 2008 and three separate NICs are used for the three external Edge roles then some routing problems can typically be seen. Previously on Server 2003 this was not a problem, but something has appeared to change in the behavior of Server 2008.

Well here is the story. (Do not miss the final paragraph as there is an important point that might make the rest of this article moot!)

OCS Edge on Windows Server 2003

Let us first revisit a proper configuration of an Edge Server when using multiple external interfaces.

Although this example is using private IP addresses with a single consolidated R2 Edge (with a static NAT compatible firewall) the scenario still holds true if publicly routable IP addresses are used instead.

Interface Role	IP Address	Subnet Mask	Default Gateway
Internal Edge	10.1.1.30	255.0.0.0	<not defined>
Access Edge	172.16.1.31	255.255.255.0	172.16.1.1
Web Conferencing Edge	172.16.1.32	255.255.255.0	<not defined>
A/V Conferencing Edge	172.16.1.33	255.255.255.0	<not defined>

Because internal networks are ‘known’ and external clients could be coming from anywhere in the public Internet IP address space (assuming Public IPs are used like in this example) then the single default gateway for the server should NOT be defined on the internal interface, but on an external interface.

Additionally, a static route would be defined to route traffic to/from the internal subnet(s). Not only do the Front-End and other OCS servers need to communicate directly with the Edge internal interface, so do any internal client workstations. For example, A/V sessions between internal and external clients travel from the internal workstation to the Edge internal interface, and out the external interface to the external client. This is why it’s important to make sure that the Edge internal FQDN is published in the internal DNS zone and not just setup on the Front-End server as a HOSTS file entry.

Since static route needs to include more than just the Front-End server, it should be define the entire, routable internal network. If multiple subnets are used internally then either a larger mask would need to be used (if all networks are configured in the same IP numbering scheme) or multiple static route will need to be added to include any and all networks where OCS servers, clients, and devices may reside.

route add –p 10.1.1.0 mask 255.0.0.0 10.1.1.1

Also we must not forget to go into the all of the external interface’s TCP/IP Advanced Properties and disable the option for Register this connection’s addresses in DNS.

The above configuration works on Server 2003 because the operating system adheres to what is called the Weak Host Model in networking. This means that all outbound traffic leaves the server on a loosely defined ‘primary’ external interface. In our scenario the Access Edge interface would hold this title as it has the default gateway defined on it, while the other externally-facing interfaces do not have a default route defined. This means that inbound traffic from external clients which hits the Edge server on any of the different interfaces would complete it’s return trip out of the single primary interface, as shown in the diagram below:

OCS Edge on Windows Server 2008

Windows Server 2008 by default now uses the Strong Host Model which no longer contains the premise of a ‘primary’ interface role among the multiple NICs. (For an excellent article on how all of this works, take a look at The Cable Guy’s article Strong and Weak Host Models.)

This now means that traffic which enters a specific interface will always be sent back out the same source interface, as shown in this diagram:

Clearly the initial benefit that can be seen is that traffic is now segregated and bandwidth more efficiently utilized than before with the Weak Host Model. External Office Communicator clients will be able to sign in and federation will function, but external Live Meeting won’t connect and no A/V and desktop Sharing features will work. This behavior also makes it easier to design routing and firewall policies as return traffic can be predicted correctly and like-communication rules can be bound together in the same firewall policies.

But using the same configuration as on Server 2003 does not work for Server 2008. (For now ignore the Default Gateway icons in the diagram above on the Webconf and AV Edge interfaces. This would then represent the typical configuration based on previous rules, but as we cover a potential resolution in the next section then those icons will come into play.)

This is because when the Web Conferencing and A/V return traffic leaves the server it will exit on the same interface it originally came in on. And since the Default Gateway is blank on those two interfaces, that traffic will not find the router and simply fail. It’s easy to confirm that behavior by watching traffic on the external firewall and by capturing packets on the server, as return traffic is lost when no usable outbound route can be found for the outgoing interface.

So there are actually two ways to resolve this in Server 2008. I’ve struggled with being able to get a ‘best practice’ recommendation from anyone on this problem, and Microsoft has yet to update any TechNet articles addressing this. The main reason is there really is not a single solution. In my opinion and from the feedback of other MVPs and SMEs in the product area it really depends on the network configuration and how the Edge Server should be configured to handle and route traffic.

Use Multiple Default Routes

One approach is to simply set the same Default Gateway on each of the external interfaces. Now normally you wouldn’t want multiple default routes defined on the same server. When multi-homing a Windows Server to different IP subnetworks (as we have here with the separate internal and external NICs on the Edge server) then factors like Dead Gateway Detection come into play, and following that general practice is correct.

But with multiple interfaces connected to the same IP subnetwork and be used to segregate traffic and not simply load balance traffic, then each adapter needs to have a valid next-hop route defined in order for the Strong Host Model to be used.

Interface Role	IP Address	Subnet Mask	Default Gateway
Internal Edge	10.1.1.30	255.0.0.0	<not defined>
Access Edge	172.16.1.31	255.255.255.0	172.16.1.1
Web Conferencing Edge	172.16.1.32	255.255.255.0	172.16.1.1
A/V Conferencing Edge	172.16.1.33	255.255.255.0	172.16.1.1

The potential pitfalls with this solution is that any of the three interfaces could be used for initiating outbound communications. Checking the route table afterwards will show that all three defined routes have the same metric value. For responses to inbound traffic this is not a problem as the Strong Host model will dictate that the response leaves the interface it entered on and external firewalls will see the return traffic from the same IP and routing should be fine. But for initiating an outbound connection, as can happen when an internal users tries to start an IM conversation with a Federated or PIC user, needs to travel out of the Access Edge interface to match the traffic profile that firewalls would be configured for (TCP 5061 outbound). Typically this works usually since the Access Edge was the first configured external interface, but because the Strong Host Model does not officially assign a primary interface then it seems to be a little luck or black-magic.

A way to force the Access Edge interface to act as a primary default route interface would be to leave the Default Gateway set on the interface properties, and then perform a route print to identify the Metric value of that route. Then instead of adding the same Default Gateway value on the other two interfaces simply create a static route from the command line and assign a metric of higher value to each of the other interfaces. This will insure that the Access Edge interface is used for initial outbound connections but when Strong Host attempts to reply to traffic from any of the 3 interfaces there is a defined route on each interface.

Configuring Multiple Default Gateways

Start by verifying that the Access Edge interface is the only external interface configured with a Default Gateway.

Issue a ROUTE PRINT command to identify the assigned metric for the Access Edge interface’s default route entry, as well as the defined indexes for each external NIC. In the example below the Index values are 14, 15, 16 for the external NICs and the default route’s Metric is 276.

C:\>route print
===========================================================================
Interface List
16 ...00 15 5d 67 a2 0f ...... Microsoft VM Adapter #4 (AV Edge)
15 ...00 15 5d 67 a2 0e ...... Microsoft VM Adapter #3 (Webconf Edge)
14 ...00 15 5d 67 a2 0d ...... Microsoft VM Adapter #2 (Access Edge)
12 ...00 15 5d 67 a2 0b ...... Microsoft VM Adapter (Internal Edge)
1 ........................... Software Loopback Interface 1
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface Metric
          0.0.0.0          0.0.0.0       172.16.1.1      172.16.1.31    276
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1 255.255.255.255         On-link         127.0.0.1    306
127.255.255.255 255.255.255.255         On-link         127.0.0.1    306
         10.0.0.0        255.0.0.0         10.1.1.1        10.1.1.30     11

Alternatively the NETSH command can be used to identify the interface indexes.

C:\>netsh interface ipv4 show interface

Idx Met   MTU   State       Name
--- --- ----- ----------- -------------------------------
1   50 429467 connected   Loopback Pseudo-Interface 1
12    5 1500   connected   Internal Edge
14    5 1500   connected   Access Edge
15    5 1500   connected   Webconf Edge
16    5 1500   connected   AV Edge

Issue the following persistent ROUTE commands to set higher metric values for the other interfaces.

route add –p 0.0.0.0 mask 0.0.0.0 172.16.1.1 metric 277 IF 15
route add –p 0.0.0.0 mask 0.0.0.0 172.16.1.1 metric 278 IF 16

Disable the Strong Host Behavior

An alternative approach would be to disable that default functionality and configure Server 2008 to use the Weak Host Model. This would allow the same single-external Default Gateway definition, but has some inherent drawbacks. Especially now with R2 a consolidated Edge Server can more easily host all external roles on the same physical interface (since NAT restrictions have been loosened). This being the case, a benefit to using multiple physical interfaces for each external role is to increase bandwidth and segregate traffic. Thus reverting the server back to a Weak Host Model could inherently negate those benefits. But on the flip side with an Edge server that handles a lot of AV communications (which require more bandwidth than others) then using Weak Host would effectively offer dedicated NIC for internal AV with outbound AV travelling over the ‘primary’ Access Edge interface, thus balancing A/V traffic across 2 interfaces. Keep in mind that the actual benefits may vary here depending on the duplex mode of the interface and switches since the two streams are in opposite directions.

Enabling Weak Host Send/Receive

Use the ROUTE PRINT or NETSH commands shown in the section above to identify each interface’s index value.

Verify each adapter’s current Weak Host settings

C:\>netsh interface ipv4 show interface 14

Issue a set of commands for each interface to enable Weak Host sending and receiving.

netsh interface ipv4 set interface 14 weakhostsend=enabled
netsh interface ipv4 set interface 14 weakhostreceive=enabled

netsh interface ipv4 set interface 15 weakhostsend=enabled
netsh interface ipv4 set interface 15 weakhostreceive=enabled

netsh interface ipv4 set interface 16 weakhostsend=enabled
netsh interface ipv4 set interface 16 weakhostreceive=enabled

Verify the setting changes on each adapter with the NETSH command again.

C:\>netsh interface ipv4 show interface 14

Summary

Although it’s a bit more complicated, attempt the first option as clients have typically configured their firewall rules to flow traffic in/out on the same interfaces. And in some instances I’ve seen clients simply set the default gateway values on each interface’s properties without mucking around with metrics and command line strings, and everything just worked fine. Go figure!

But if internal routing issues seem to prevent that approach from working, then disabling Strong Host will also get the job done and is an easier configuration on the server side. Changes may need to be performed on the firewall to handle inbound and outbound traffic of the same type to/from different IPs, but being armed with this information ahead of time though can make this an easier process.

So all this stuff leads me to one important point that can save a ton of work and headaches up front. Simply ask the question: “Why are there 3 externally-facing physical interfaces in the Edge server?”

With NAT support for consolidated Edge in R2 there are now even less deployments with separate physical external interfaces (due to different subnetworks connected to AE/LM and AV roles, but even that scenario is slightly different because the of the unique networks which don’t share the same default route anyways). Physical traffic segregation and bandwidth are the only real arguments for having multiple external interfaces, and with gigabit interfaces in servers being the norm these days bandwidth limitations might be perceived more than actual. Besides, once that level of traffic flow is reached it is typically a better approach to deploy a second Edge server and expand into a pool than simply add multiple interfaces to a box that still has to flow all of that data back into a single NIC to connect to the internal OCS servers after all. So if any single recommendation were to come out of this article it would be to make sure that 3 external interfaces are really needed in the first place!

Category: Office Communications Server

Published: 9/17/2009 9:18 AM

Categories: Office Communications Server

More on OCS Edge Server Certificates

Jeff Schertz — Tue, 22 Sep 2009 21:39:56 GMT

Body:

There are a pair of related Office Communications Server 2007 topics I wanted to expand on from previous blog articles that I’m still seeing come up quite often in both day-to-day projects and in the Microsoft discussion forums. One of them is centered around adding and supporting additional SIP domains. And because the two most common topics in OCS-related issues are Certificates and the Edge Server, it makes sense that deploying certificates on an Edge Server might just be the other topic. Although the screenshots and details will be specific to the more current R2 product, all of these requirements and recommendations apply equally to both 2007 releases.

Edge Server Certificates

So it is probably a good idea to first review the certificate requirements and spell out an important point that is not always clear to the first-time reader of the documentation. Way back in November 2007 I posted an in-depth article that covered many facets of the Edge Server which included this very breakdown of certificate requirements:

Internal Interface
- Issued by internal Windows Enterprise CA
- Subject Name is the server's FQDN (e.g. ocsedge.contoso.local)
Access Edge Server
- Issued by trusted third-party certificate authority
- Subject Name is the FQDN used by the client to connect (e.g. sip.contoso.com)
Web Conferencing Edge Server
- Issued by trusted third-party certificate authority
- Subject Name is unique FQDN (e.g. webconf.contoso.com)
A/V Authentication Edge Server
- Issued by internal Windows Enterprise CA
- Subject Name is unique FQDN (e.g. av.contoso.com)

This outline mirrors the requirements spelled out in the Certificate Requirements for External User Access portion of the official documentation. The recently released Certificate Deployment White Paper also further enforces this recommendation. That said, it is possible to use the same certificate on both the Access Edge and Web Conferencing roles,

The key point to understand from the requirements is that the A/V Conferencing Edge service does not use, nor require a certificate. But the A/V Authentication service does require a certificate. This separation can be easy to confuse since the A/V Conferencing and A/V Authentication components can often be misunderstood to be one in the same. Technically they are part of the same core role (A/V Edge) and both used for audio and video communications (as well as Desktop Sharing in R2), but are in fact two separate, distinct services:

The terminology can be a bit cloudy as the A/V Conferencing Edge is also sometimes referred to simply as the A/V Edge role (as seen above in the Services applet). An important distinction between the two services is that the A/V Conferencing is an externally-listening service while the A/V Authentication is internally-listening service, as shown in the Edge Interfaces property tab:

The OCS Certificate Wizard probably best depicts this as A/V Authentication Certificate option is quite clear here:

The other important clarification from the documentation above is that the A/V Authentication service (being an internal communications service) does not require a certificate from a trusted third-party Certificate Authority. The same internal Enterprise CA that issues the Internal Edge certificate should be used for A/V Authentication, but not the same certificate; each role should have its own dedicated certificate. Of course if no internal CA is available then a trusted public Issuing CA can be used for any and all of the roles, it’s just more costly.

Why use Dedicated Certificates?

I’ve seen all the arguments for wanting to use a single certificate for all the Edge Server roles and they almost always break down to a single issue: Cost. And companies on a tight budget certainly can and will balk at the first sight of the needing 4 certificates, especially if the deployment of an Exchange 2007 Server certificate with all 147 SAN entries is fresh in their minds.

But when comparing costs of the certificates for a single, simple deployment of OCS it can actually be cheaper to purchase multiple certificates instead of one. First off, it has been established that 2 of the certificates should be issued by an internal private CA which is typically handled by an in-place Windows Server Enterprise Certificate Authority. Cost so far: $0.

This leaves only the two remaining externally-facing, certificate-requiring services: Access Edge and Web Conferencing Edge. The typical argument is to attempt using the same certificate on both roles in order to ‘save money’. But a more costly SAN certificate would be required as the Common Name value in the Subject Name field would need to be set to the Access Edge FQDN (typically sip.domain.com) while the Web Conferencing Edge FQDN would need to be included in the Subject Alternative Field (SAN) (e.g. webconf.domain.com). Most of the major players in the field offer UCC or SAN certificates at roughly more than double the cost of their standard SSL certificates. For example, looking at Digicert’s current offerings one can see that the cost of a single UCC cert for 1 year is $328 but the cost of two separate standard SSL certificates would be $144 each, at a combined cost of $288. Thus, it is pretty hard to argue against best practice recommendations when it also ends up being more expensive.

Additional SIP Domains

But if an organization is required to support more than one SIP domain with Automatic Sign-In for external user access or for anonymous external Live Meeting access then the above cost savings comparisons are not as relevant. Following is a brief review of why these two requirements might impact certificate costs.

Assume the above configuration is in place with a single supported SIP domain of contoso.com. Once a second SIP domain (fabrikam.com) is required for external access, then a whole chain of dependencies is put into place:

If a user with a sign-in name in the additional SIP domain (jeff@fabrikam.com) needs to login externally via Edge using Automatic Configuration with Office Communicator then there will need to be a publicly-resolvable SRV record (_sip._tls.fabrikam.com) in the same domain as the OCS user’s sign-in domain.
That SRV record must point to an A record in the same domain (sip.fabrikam.com), it cannot point to an A record in another domain (like sip.contoso.com) as then the Automatic Configuration process would fail.
Because the OC client is given (via DNS) the hostname of sip.fabrikam.com to connect to for Access Edge services, the assigned certificate on that Edge server must include that hostname. If it is currently only configured with a Common Name of sip.contoso.com then the OC client will fail to connect with a certificate name mismatch error.
Additionally if that same user sends a Live Meeting initiation to a foreign party with the intention of having them join the meeting anonymously over the Internet, the sending user’s SIP domain (fabrikam.com) is what the anonymous user’s Live Meeting client will perform an SRV record lookup against. This puts the anonymous Live Meeting client into the same scenario as the Office Communicator client using Automatic Configuration.

This means that the Access Edge certificate needs to have entries for both SIP domains (sip.contoso.com and sip.fabrikam.com) moving it up into the more expensive SAN-certificate category. But for the same reasons as shown in the process above the Web Conferencing Certificate does NOT require modification. Only the Access Edge FQDN needs to be resolved in some way by clients and once a connection is made from the client, all other service FQDN values (Web Conferencing, A/V Conferencing, External Web Farm, etc) are passed in-band to the OC or LM client. Regardless of what SIP domain a user signs in with (@fabrikam.com) the other services are all still configured with a single FQDN value using the original primary SIP domain (webconf.contoso.com, av.contoso.com).

Now the certificate cost scenario is a bit more of a debate than before. When supporting a single SIP domain the cost savings was $40/year to go with the best practice recommendation of dedicated certificates. But with the requirement of at least one SAN cert there are two viable options:

Replace the Access Edge certificate to a SAN certificate (and leave the standard certificate on the Web Conferencing Edge) at a total cost of $472/year. This solution retains the more secure, best practice approach that will be easier to troubleshoot and manage over time.
Replace both the Access Edge and Web Conferencing Edge certificates with a single SAN certificate for $288/year and insert the Web Conferencing Edge FQDN into the SAN field in addition to all supported SIP domains.

Regarding choice #2, if the same certificate is assigned to both Access Edge and Web Conferencing Roles then the configuration will look a little strange on the Web Conferencing Edge properties. Since the certificate’s Common Name would be the sip.contoso.com entry, then that entry would be displayed as the FQDN, and not the desired webconf.contoso.com entry which is stored in the certificate’s SAN field:

This would seem like it should cause a problem, but it actually does work. This is because the Web Conferencing FQDN that is handed out in-band to connecting clients is actually pulled from a different setting in OCS and not the value shown above, which is simply reflecting a portion of the certificate’s Subject Name. The actual Web Conferencing External FQDN is stored in Active Directory and is configured on the internal server by accessing the Web Conferencing Edge Server tab on the pool’s Web Conferencing Properties in the OCS management console:

But ultimately, if neither of the automatic sign-in or anonymous access features are required (thus Manual Configuration will be used for all external Office Communicator and Live Meeting client connections) then the original SAN-less certificates can be retained as all external services will be resolved and connected to using the current A records in the primary contoso.com domain, regardless of how many additional SIP domains were added.

Category: Office Communications Server

Published: 9/22/2009 4:39 PM

Categories: Office Communications Server

OCS Communicator Web Access Listening Port

Jeff Schertz — Thu, 24 Sep 2009 13:26:14 GMT

Body:

During the deployment of an OCS Communicator Web Access Server there is a setting that is not covered in much detail in the documentation: the Communication Server Listening Port. No default or suggested value is given, as shown by this screenshot of the virtual server creation wizard:

This port is used by the Communicator Web Access Server to listen for inbound communications from other OCS servers. When an additional Virtual Web Server is added to the same host, as is common when both Internal and External types are setup on the same server, the new virtual site’s listening port must be on a different port then what the initial site is configured for, otherwise the following error will appear:

This is also a common error when attempting to use a standard OCS port (like 5061) when CWA has been installed on an OCS Front-End server (such collocation is unsupported) . Since the Front-End services already occupy that port then an unused port must be specified. If CWA is installed on a separate server (as it should be) and the first, internal virtual site activation accepts 5061 as a value but the second virtual site activation does not, then it can be a bit confusing since one might think that there should not be a port conflict if the second site is configured on it’s own IP address.

Even though both virtual sites should be setup on different IP addresses, so that the default TCP 443 value can be used for the IIS site, all back-end OCS server communications still happen on the host’s primary IP address, which is what is resolved by DNS for the server’s FQDN. It’s common practice to set the first virtual site configured during the initial CWA deployment to 5061, and additional sites can be set for values of 5062, 5063, etc. There is no requirement on what port is used, except that it can’t already be in use on the host server.

For example, assume a CWA Server is configured with both an Internal and External virtual site, using the following configuration:

Description	FQDN	IP Address	Port	Listen Port
Communicator Web Access Host Server	ocs02.schertz.local	192.168.207.14
Virtual Web Server 1 - Internal	https://im.schertz.lab	192.168.207.14	443	5061
Virtual Web Server 2 - External	https://im.schertz.lab	192.168.207.15	443	5062

The way that the settings are displayed in the Communicator Web Access management console, it almost appears as if those listening ports are associated with the same IP address that the virtual web site is:

But that is not the case. There are a couple ways to verify exactly which IP address each Listening Port is actually listening on by using either simple netstat command or by capturing traffic on the server. The following diagram shows the basic traffic flow of two separate conversations, one between Workstations 1 and 2, and another IM session between Workstations A and B. The workstations on the left-hand side are typical Office Communicator users while those on the right-hand side are using Communicator Web Access with a web browser. Workstation B is located outside the corporate network and is directed through the firewall to the External CWA site running on the second IP address.

Below is a screenshot of a Network Monitor session with captured traffic from the two separate IM conversations:

Instant messages sent from Workstation 1 to Workstation 2 appeared on the CWA server as coming from the OCS Front-End server (OCS01) and were directed toward the CWA server (192.168.207.14) to port 5061.
Instant messages sent from Workstation A to Workstation B also came from the same Front-End server and were directed to the CWA server on the same primary host IP address (192.168.207.14), but were sent to port 5062, and not to the external virtual site’s IP address of 192.168.207.15.

Additionally, a netstat command can be issued at the same time to validate that the listening ports (5061 & 5062) are only established on the same, primary IP address. (This only displays active connections so if no users are currently using CWA then the ports won’t be listed.)

Changing the Listening Port

Unfortunately the Communicator Web Access management tool does not offer the ability to change the configured listening port after the virtual site has been created. The only port values which can be modified in the virtual server’s properties are: the client-connection port (which appears on the Connectivity tab and is typically set to 443) and the next-hop connection port (shown on the Next Hop tab, usually 5061). The latter is actually the remote listening port on the Front-End server that CWA will attempt to connect to. Nothing here about listening port that CWA itself is using for each virtual site.

The only way to change this setting is to manually update the TrustedServiceListeningPort WMI property.

On the CWA server run wbemtest.exe to access the Windows Management Instrumentation Tester application.
Click Connect.
Clear the ‘Namespace’ field and enter root\default\rtccwa_repository and then click Connect.
Under ‘IWbem Services’ click on Open Class.
In the ‘Get Class Name’ window enter MSFT_CWASiteSetting for the Target Class Name.
Click Hide System Properties to help filter the list a bit.
Click on Instances to see a list of installed CWA Virtual Servers.
Double-click on the desired instance to view the properties. To identify the instances compare the ‘Description’ property value with the description name shown in the CWA administrative tool, as shown below:
Highlight the property TrustedServiceListentingPort and click Edit Property.
The configured value is stored in both decimal and hexadecimal so be careful changing the value to insure that the format is not altered incorrectly. Simply update both values (use the Calculator in Programmer mode to validate both formats are equal).

For example, change the port from 5062 to 1975 (7B7 in hex) and click Save Property.
Click Save Object. at the ‘Object Editor for MSFT_CWASetting.Name’ window.
Click Close, Close, Exit.
Refresh the CWA Management console window and the new port setting should be displayed.
Issue a Restart on the specific virtual site in the CWA management console to complete the change.

Category: Office Communications Server

Published: 9/24/2009 8:26 AM

Categories: Office Communications Server

OCS TechNet Forum Reorganization

Jeff Schertz — Tue, 10 Nov 2009 17:22:08 GMT

Body:

This week Microsoft has begun the process to migrate all the current discussion forums for Unified Communications-related topics into a single category. As with any migration there is both an upside and a downside to these changes. Most importantly, going forward it will be much easier for users to locate the correct forum in which to pose a question on a specific OCS-related problem they are experiencing as there are not many different categories across multiple sites with similar topics to choose from. But on the downside none of the current content can be ‘pushed’ into the new forums. So all of the past discussion, full of helpful content, will still be located in the old forums as an archive.

Microsoft TechNet Forums - Office Communications Server
http://social.technet.microsoft.com/Forums/en-US/category/ocs

So I thought I would take some time to break down the reorganization that I assisted with in designing to make it easier to locate for anyone looking for older content. First off, here is the new streamlined configuration of 15 forums all located under a single category:

TechNet Forums \ Office Communications Server

And here are all the past forums and categories which are planned to be locked down to prevent new posts and will be retained indefinitely as archived contenting for searching and browsing. This list totals 33 forums under 6 categories across 2 separate sites (social.microsoft.com and social.technet.microsoft.com).

Microsoft Forums \ Unified Communications Conferencing

Microsoft Forums \ Office Communications Server Public Beta

Microsoft Forums \ Office Communications Server

Microsoft Forums \ Unified Communications Integration

Microsoft Forums \ Office Communicator

TechNet Forums \ UC Community Readiness

Each of the old forums now contains a ‘sticky’ post which describes the reorganization, explains that the forum will soon be locked to prevent new posts, and contains a link to the new OCS forum category:

Additionally, each new forum also contains a ‘sticky‘ post that contains links back to only the archived forums that contain discussion related to the same topic as that specific new forum.

So for example the new ‘Planning & Deployment’ forum contains links back to all of the previous forums related to setup and deployment tasks, while the new Certificates forum only points back to the previous Certificates forum.

A big ‘thanks’ goes out to all in the product and forum teams who have worked at getting these changes applied. Now that the OCS forums are in their rightful place on TechNet alongside the other server product forums, everyone from users to moderators should more easily be able to locate and update content.

Category: Office Communications Server

Published: 11/10/2009 11:22 AM

Categories: Office Communications Server

My Laptop is Trying to Fly Away...

Jeff Schertz — Tue, 31 Jul 2007 23:19:26 GMT

Body:

...or so it seems, judging by the excessive noise coming from my laptop's fan recently. My Dell Latitude D820 is only a little over six months old, but in the past few weeks it has been running noticeably hotter, regardless of CPU load. Within 5-10 minutes of a cold-boot the measured CPU temperature would steadily climb to over 70°C, which was followed by the system fan stepping up to it's maximum speed in a fruitless effort to displace heat. This abnormal amount of heat was radiating mostly from the bottom center of the laptop, directly below the CPU. The excess heat and noise were fast becoming both a nuisance and a source of concern.

I ran a full diagnostics sweep from the bootable CD, but no problems were reported. Since my initial thought was that it might be a build-up of dust inside the system, so I removed the keyboard and visually inspected the top of the system board, heat-sink assembly, and fan. The system was very clean and there was almost no surface dust, much less any considerable build-up. Unwilling to void the manufacturer warranty by poking around in a company-supplied computer, I clicked over to Dell's webpage and initiated a customer support chat session which ended in a scheduled next-day visit from a Dell certified technician carrying a new Processor Thermal-Cooling Assembly and Fan Assembly. I wasn't too convinced that replacement of these parts would cure my problems as the fan itself was obviously working correctly, but was just unable to keep up with the amount of heat the system was producing.

Well, as soon as the technician removed the cooling assembly the problem was evident: a massive layer of dust about 1/4" in thickness completely enveloping the inboard side of the heat-sink fins. Unfortunately there is no good way to reach that area of the computer without removing internal components, so I was unable to see it previously. Even though he replaced it with a new part, I'm sure that reinstallation of the original components would have been fine now that blockage had been pulled from the cooling system.

In the diagram below (shown without the fan assembly), the bottom and side case vents are used for intake of cooler, outside air which is forced past the heat-sink fins and then out through the rear exhaust vent.

Processor Thermal-Cooling Assembly:

The copper/metal hybrid cooling assembly pulls heat away from the core components, toward the heat-sink fins where the fan pushes outside air through them and out of the case. With the intake portion of the fins completely blocked the system fan would just run at full speed, but unable to properly remove the hot air from the case.

This graph shows recorded CPU temperatures over 40 minutes during idle and light-usage:

The red line is before removing the dust build-up, and the blue line as afterwards. Two things are apparent from this graph, that the CPU temperature has dropped about 20°C and some downward trending can now be seen. The 'before' line shows that the system was fighting a losing battle against core temperature as I noted that the fan was running at 100% the entire time. But the data collected after the repair shows that even though system fan was running at very low speeds it was still able to lower temperatures quickly.

Preventative maintenance will keep these laptops running cooler over time, and in turn extend their usable lifespan. I'd recommend periodically blowing compressed air into the rear exhaust port (make sure the laptop is turned off) directly into the metal cooling fins. This should prevent any measurable build-up of dust that might begin to block off the fins entirely.

Published: 7/31/2007 8:58 PM

Vista WiFi Auto-Connect Workaround

Jeff Schertz — Thu, 04 Oct 2007 14:31:56 GMT

Body:

Since upgrading from Windows XP to Vista Business at the start of this year I have learned to live with a few behavioral annoyances by either adapting the way I previously performed a specific task or digging up a workaround/fix. Alas, there are still two specific issues that continue to drive me up a wall, day after day. The first of which was documented by Mark Russinovich in his blog entry entitled The Case of the Delayed Windows Vista File Open Dialogs and has me eagerly awaiting the release of Service Pack 1. Since I'm constantly logged into my laptop with cached domain account credentials while rarely actually connected to our home office I see this constantly.

The second issue is related to connecting to wireless networks. First off I have yet to understand the overly-complex and poorly-executed Network and Sharing Center that Vista uses. Tasks that were straight-forward and simple in XP have become cumbersome, and in some cases not even possible in Vista. One such example in particular is the way that wireless networks are managed and configured. Viewing multiple connection profiles is very clunky and requires switching between windows to effectively re-order networks as the View options are disabled and the is no column for profile affinity in that view.

But the biggest oversight is the fact that when a profile is set to automatically connect to a wireless network, the option to manually connect it is not available.

So let's take a closer look at this behavior:

The properties window for a wireless network connection named "Guest" shows that the setting for Connect automatically when this network is in range is not enabled.

This profile will appear in the Connect to a network window and the right-click menu presents the option to Connect or Disconnect, depending on current connection state.

But this configuration requires that the user manually connects to this network each time the computer is started, brought out of hibernation/sleep, or enters the range of the wireless network. Since computers are supposed to make life easier, let's configure this profile to automatically connect to the network.

Unfortunately this configuration now completely removes the connection profile from the Connect to a network window, meaning we are relying on Vista to automatically connect. If for some reason the network is in range but Vista is not connecting, the only way I've found to succesfully connect through the GUI is to go back to that wireless network's connection properties, unselect the 'automatically connect' option, go back to the connect window, right-click and choose connect. Then go back to the properties again and revert that setting so that auto connect is still re-enabled for future attempts.

Well, I gave up doing all that long ago and simply set all of my wireless networks to not automatically connect as on any given day I'm moving between 3-4 different WiFi networks. My previous laptop with Windows XP did a much better job of automatically connecting to wireless networks, but my new laptop paired with Vista fails to connect the majority of the time. Even replacement of the internal WiFi card did not help. It seems that I had the most success when booting up the system while in range of a network, but almost daily I put the computer into sleep mode while connected to one network and then wake it up in the range of another network as I move from home office to work office to client sites to public networks and it rarely works. So each time I logon I have to manually connect to a network, which I think is a bit ridiculous. And forget about trying to create a shortcut to the network connection on your desktop for quick clicking, Vista doesn't allow that either.

Luckily there is a simple workaround that has let me configure each wireless network to automatically connect yet doesn't require that whole song-and-dance routine each time that fails to work and I'm forced to manually connect (which is quite often). The native netsh command can be used to connect/disconnect to a wireless network using the wlan option.

C:\>netsh wlan connect /?

Usage: connect [name=]<string> [[ssid=]<string>] [[interface=]<string>]

Parameters:

Tag Value

ssid - SSID of the wireless network.

name - Name of the profile to be used in connection attempt.

interface - Name of the interface from which connection is attempted.

Remarks:

Connect to the wireless network given by ssid using the specified

profile. Connection is attempted from the specified interface unless

there is only one available interface on the system, in which case,

the interface parameter can be omitted.

Parameter profile name is required but ssid is optional. If only one

SSID exists in the profile, then this SSID is used to connect. If there

are multiple SSIDs in the profile, then parameter ssid is required.

Parameter interface is required if there are two or more available

interfaces on the system. When interface is specified, it cannot be

a wildcard name.

If the specified interface is already connected to a wireless network,

this command will first disconnect from the currently connected network,

then attempt to connect to the new network. However, if these two networks

are the same this command simply returns success and does nothing.

Examples:

connect name=Profile1 ssid=SSID1

connect name=Profile2 ssid=SSID2 interface="Wireless Network Connection"

So, using the example above we can create a simple command to force a connection attempt to the wireless network and this works regardless of wheter the profile is set to automatically connect or not, something we can't do with the GUI. The command would be:

netsh wlan connect name=Guest ssid=Guest

Although the request was successfully received, this does not confirm that the network actually connected, but just keep an eye on the Network systray icon for activity or hover over it to see the status.

Now just put that command into a script or shortcut. I plan to play around with a Startup script that will execute a command for each of my 3-4 most used wireless networks to possibly automate it even more.

Update:

Ok, so the search for a final solution continues. I've discovered after a reboot that even the netsh command fails when a Wireless Connection Profile is set to auto connect. The command errors out with "The network specified by profile "PROFILE NAME" is not available to connect."

So I've left the profiles set to not automatically connect, and basically all I've accomplished is found a slightly faster way to connect to networks, yet still 100% manually, after starting up the computer. Ugh.

Category: Windows Vista

Published: 10/4/2007 10:59 AM

Categories: Windows Vista

ISA 3-Leg Perimeter Network with Private IP Subnet

Jeff Schertz — Mon, 22 Oct 2007 02:35:55 GMT

Body:

In a future blog entry I plan to walk through many of the steps needed to setup a virtualized test environment running on a single, uni-homed host. Throughout the process I've used a combination of online articles and blogs with input from colleagues to try and find the simplest hardware configuration which would allow me to deploy many different Microsoft products in an environment which closely mimics a typical enterprise.

While I'm still working on that documentation, one specific hurdle that is worth calling out separately is related to Internet Security & Acceleration Server 2006 which is the core networking component used in my lab. Without getting into too much detail, I have ISA Server 2006 deployed within a Windows Server 2003 virtual guest machine which is multi-homed across three networks: two virtual networks controlled by VMware Server and a third virtual NIC bound to the physical host's single NIC.

Because I'm running my test lab at home behind a broadband connection I'm limited to a single dynamic public IP address, so the individual networks are all using private IP address ranges, with natural-mask Class C addresses used on my physical Ethernet network as well as the virtual Internal Network. An unnatural-mask Class B address range was configured for the Perimeter Network, as seen in this diagram:

Once I had ISA Server 2006 installed and deployed in the first virtual machine, I promptly used the 3-Leg Perimeter template to define the network configuration within ISA. As it turns out this template is designed to be used in a specific scenario and caused major problems with IP routing when I used it with my network configuration. After some research I discovered that the template is really meant to be used with a Perimeter Network that is configured with a public IP address range, NOT a private range.

The default behavior can be seen in the Network Relationship settings for the Perimeter Configuration and Perimeter Access network rules:

Traffic between the Internal Network and Perimeter Network is set to NAT (Network Address Translation) and traffic between the Perimeter Network and External Network is configured as Route. This behavior assumes that a Private IP address range is used in the Internal Network and a Public IP address range is used in the Perimeter Network.

Because I was using Private IP address ranges in both of these networks I needed to flip the configuration of both network rules:

This configuration now allows the ISA Server to route all traffic between the Internal and Perimeter Networks without performing any unneeded Network Address Translation, while correctly translating the traffic between non-routable Private IP addresses in the Perimeter Network and the hosts in the External Network. (Keep in mind that Firewall Policy rules will still be required to successfully route traffic between these networks, but the important first-step of connecting the separate networks is completed.)

It's a simple configuration change that if over-looked will cause all sorts of problems when attempting to publish services to the Internet on hosts in the internal networks.

Published: 10/21/2007 9:46 PM

Renaming an OCS Standard Server

Jeff Schertz — Sat, 27 Oct 2007 20:46:35 GMT

Body:

…is not a good idea. In a production deployment a second server should be built using the desired server name, and then all OCS users moved over to it. Or a temporary staging server can be stood up in order to rebuild the original server. Either way, simply renaming an Office Communications Standard Server 2007 can be painful.

Shortly after deploying a standard server in my lab I noticed during server configuration that I had fat-fingered the server's hostname and was not to happy about that. I decided to see what would happen if I just renamed the server without any preparation in OCS. After renaming my virtual guest from JDSSOCS01 to JDSOCS01 I was welcomed with a standard Windows startup message alerting me to a service failure.

A quick scan of the Application event log uncovers event ID 12291 explaining that "the Communications service is registered for a different machine." Microsoft Knowledgebase Article ID 830535 covers this error, but in reference to LCS 2003, and states that changing the FQDN of a Live Communications Server is not supported. So it doesn't appear to be supported in OCS 2007 either.

The article's resolution suggests exporting the RTC SQL database to a file, removing the OCS services, and re-installing the product. Because I had already renamed the server I was unable to deactivate the pool/server using the previous name and was presented with a couple warnings during the uninstall that some configuration information will be left in the Active Directory domain; I took note of this for later troubleshooting. I also completely removed the SQL 2005 Express components in order to wipe the OCS install from the server.

During reinstallation of the OCS Standard Server the setup wizard reported a failure and viewing the install log showed that the server could not be activated for a pool due to a conflict. At this point I decided to just delete the VM and rebuild the server from a fresh image as deploying a clean lab environment was my overall goal. Before creating a new server with the desired server name of JDSOCS01 I went to delete the existing computer object in Active Directory, but oddly enough I was warned that deletion of that object would result in all child objects also being removed from AD. I checked out the existing computer object using ADSIedit and apparently the OCS installation inserts additional objects under the server:

I deleted the computer object and imaged a new virtual guest using the correct server name. This time the OCS Standard Server installation completed successfully, but I received another error after validating the front-end server configuration:

Failure: [0xC3FC200D] One or more errors were detected

Diagnose Server

Check Configuration

Checking all trusted servers

Internal Server JDSSOCS01.lab.schertz.local

DNS Resolution failure: No such host is known

Suggested Resolution: Make sure there are no typos in the Server name. Make sure that the Server name is published in the DNS (A or SRV record) or hosts file entry is configured correctly.

This is the part where I spent some time digging through AD looking for where the old server name was hiding. After running some LDAP queries using the string *pool* I discovered where OCS stores it's configuration data in AD:

CN=RTC Service,CN=Microsoft,CN=System.DC=domain,DC=com

I located and deleted the Pool object for the old server:

CN=JDSSOCS01,CN=Pools,CN=RTC Service,CN=Microsoft,CN=System,DC=schertz,DC=local

But that didn't resolve the validation errors after rebooting the OCS server. I dug deeper and found both the old and new server FQDNs referenced in multiple objects under Global Settings, MCU Factories, Trusted MCUs, and Trusted WebComponentsServers. Using the command ldifde -f output.txt -d "dc=schertz,dc=local" is was able to search the text export file for all the objects with attributes referring to "jdssocs01":

CN=Global Settings,CN=RTC Service,CN=Microsoft,CN=System.DC=schertz,DC=local

DN: CN={DB1226B0-B04E-494F-BF44-6C365A2A4CF1}

objectCategory: CN=ms-RTC-SIP-TrustedServer

msRTCSIP-TrustedServerFQDN: JDSSOCS01.schertz.local

CN=MCU Factories,CN=RTC Service,CN=Microsoft,CN=System.DC=schertz,DC=local

DN: CN={0AAB2557-E5AA-4229-8F43-600554BAE453}

objectCategory: CN=ms-RTC-SIP-MCUFactoryService,CN=Schema,CN=Configuration,DC=schertz,DC=local

msRTCSIP-MCUFactoryData: FactoryURL=https://JDSSOCS01.schertz.local:444/LiveServer/MCUFactory/

DN: CN={55753891-89EA-4F18-B020-5FA5928BE97F}

objectCategory: CN=ms-RTC-SIP-MCUFactoryService,CN=Schema,CN=Configuration,DC=schertz,DC=local

msRTCSIP-MCUFactoryData: FactoryURL=https://JDSSOCS01.schertz.local:444/LiveServer/MCUFactory/

DN: CN={56B7C1C4-1961-461A-B40F-3ABB3C62BE31}

objectCategory: CN=ms-RTC-SIP-MCUFactoryService,CN=Schema,CN=Configuration,DC=schertz,DC=local

msRTCSIP-MCUFactoryData: FactoryURL=https://JDSSOCS01.schertz.local:444/LiveServer/MCUFactory/

DN: CN={E1F6A173-E15D-427A-8E2A-87DD1CAAD947}

objectCategory: CN=ms-RTC-SIP-MCUFactoryService,CN=Schema,CN=Configuration,DC=schertz,DC=local

msRTCSIP-MCUFactoryData: FactoryURL=https://JDSSOCS01.schertz.local:444/LiveServer/MCUFactory/

CN=Trusted MCUs,CN=RTC Service,CN=Microsoft,CN=System.DC=schertz,DC=local

DN: CN={459B434F-3099-4049-8A2E-56D0524AFAD4}

objectCategory: CN=ms-RTC-SIP-TrustedMCU,CN=Schema,CN=Configuration,DC=schertz,DC=local

msRTCSIP-TrustedMCUFQDN: JDSSOCS01.schertz.local

DN: CN={51D7A033-A074-4285-9589-FB78AAB6A460}

objectCategory: CN=ms-RTC-SIP-TrustedMCU,CN=Schema,CN=Configuration,DC=schertz,DC=local

msRTCSIP-TrustedMCUFQDN: JDSSOCS01.schertz.local

DN: CN={9DE8BC35-D15A-4F8F-8BCD-A819014420F0}

objectCategory: CN=ms-RTC-SIP-TrustedMCU,CN=Schema,CN=Configuration,DC=schertz,DC=local

msRTCSIP-TrustedMCUFQDN: JDSSOCS01.schertz.local

DN: CN={C5677C4C-7BE6-484D-9CD4-878F1F8427BE}

objectCategory: CN=ms-RTC-SIP-TrustedMCU,CN=Schema,CN=Configuration,DC=schertz,DC=local

msRTCSIP-TrustedMCUFQDN: JDSSOCS01.schertz.local

CN=Trusted WebComponentsServers,CN=RTC Service,CN=Microsoft,CN=System.DC=schertz,DC=local

DN: CN={93A1A739-3B44-4F0B-935A-170EAAA63026}

objectCategory: CN=ms-RTC-SIP-TrustedWebComponentsServer

msRTCSIP-TrustedWebComponentsServerFQDN: JDSSOCS01.schertz.local

I deleted all objects above and then removed the invalid ServicePrincipalName entries from the RTCService and RTCComponentService user accounts.

I forced AD replication between both domain controllers and rebooted the OCS server, and the validation check no longer reports any failures.

Category: Office Communications Server

Published: 10/27/2007 4:25 PM

Categories: Office Communications Server

DNS Lookups with OCS Automatic Configuration

Jeff Schertz — Thu, 08 Nov 2007 03:14:07 GMT

Body:

Between the OCS 2007 Deployment documentation, official Resource Kit, and blog/forum posts I've seen some discrepancies regarding the exact names (and order) of lookups performed by an Office Communicator 2.0 client when attempting to connect to an Office Communications Server when utilizing Automatic Configuration. Specifically I've seen reference to the automatic fall-back of looking for A records starting with sip, or instead with sipinternal, and sipexternal. Well, I discovered that it's actually all three.

To view the behavior I purposely deleted the DNS records I previously created in my lab environment during initial OCS deployment. After removing the SRV record _sipinterntls._tcp.schertz.local and the A record sip.schertz.local I flushed the DNS cache on my XP guest and launched Office Communicator, and was immediately presented with the error message: "Cannot sign in because the server is temporarily unavailable. If the problem persists, contact your system administrator."

Although you can enable logging from within Office Communicator it is not neccasary as the following Application event log entries will be created during the connection failure:

Event ID: 1

Communicator was unable to locate the login server. No DNS SRV records exist for domain schertz.local, so Communicator was unable to login.

Event ID: 3

Communicator was unable to resolve the DNS hostname of the login server sipinternal.schertz.local.

Event ID: 3

Communicator was unable to resolve the DNS hostname of the login server sip.schertz.local.

Event ID: 3

Communicator was unable to resolve the DNS hostname of the login server sipexternal.schertz.local.

So it appears that if no SRV record is found then the fall-back is to look for standard DNS name records in the following order:

sipinternal.domain.com
sip.domain.com
sipexternal.domain.com

(Note: Microsoft documentation can be a little misleading in a few places as there are specific requirements on A records versus CNAME records, but this appears to refer to the name records paired with SRV records, meaning that a SRV record must always point to an A record, and not a CNAME record. but for the standard DNS fallback it appears that either a CNAME or A record will work the same.)

Next I created a new DNS Alias (CNAME) record of sipinternal.schertz.local and verified my client could resolve the new record. After reopening Office Communicator and attempting to sign-in, a slightly different error message appeared: "There was a problem verifying the certificate from the server. Please contact your system administrator." A peak at the Application log showed two new events:

Event ID: 1

Communicator was unable to locate the login server. No DNS SRV records exist for domain schertz.name, so Communicator was unable to login.

Event ID: 4

Communicator could not connect securely to server sipinternal.schertz.name because the certificate presented by the server did not match the expected hostname (sipinternal.schertz.name).

We can see that again the SRV lookup was tried first and failed, but the first name record lookup for sipinternal resolved to a server and a connection attempt must have been successful as the client received a certificate, but failed with a name-mismatch. Using the OCS management tool to access the Front End Server Properties on the server object we can see the currently applied certificate. Clicking Select Certificate, then highlighting the current open from the list and clicking View Certificate will let us look at the Subject Name and Subject Alternative Name fields under the Details tab.

The certificate verification error is reported because sipinternal.schertz.local is not in the certificate's SAN field, although sip.schertz.local is. This behavior underlines the importance of including any potential sip DNS names in the OCS server certificates.

Next I created another new DNS record for sip.schertz.local, but left the malfunctioning sipinternal record in DNS. Although there was still a certificate error when using sipinternal, Office Communicator will not continue to look for other DNS records, it simply stops at the first successful resolution regardless of what happens after a connection attempt is made to the remote server. So I deleted the sipinternal record and tested sign-in again, which worked correctly utilizing the sip.schertz.local record. At this point I recreated the previous SRV record to restore the previous configuration.

Category: Office Communications Server

Published: 11/7/2007 9:19 PM

Categories: Office Communications Server

OCS Edge Server Requires Separate Internal and External Interfaces

Jeff Schertz — Fri, 09 Nov 2007 16:28:07 GMT

Body:

I recently ran into a deployment problem for a customer where we attempted to use just two network interfaces for a single Edge Server configuration. If you follow the deployment documentation for the Office Communications Server 2007 Edge server, you'll see that they require the Edge server to have up to four separate network interface ports, one for internal and one for each of the three Edge Server Roles. From a network bandwidth standpoint in a high-usage scenario this many interfaces can be helpful, but when installing a single Edge Server containing all 3 roles it could be more efficient to potentially reduce the amount of hardware requirements.

Since the new hardware we were using to deploy the Edge server currently only had a single dual-port network interface (the additional card was back-ordered), we decided that we would locate the public IP address for the A/V Edge Server on one port, and then include the remaining three IP addresses for the Edge Access Server, Web Conferencing Server, and host's primary "internal" address all on the second port, like so:

NIC #1

10.1.1.10 - Host

10.1.1.11 - Access Edge Server

10.1.1.12 - Web Conferencing Edge Server

NIC #2

12.1.2.34 - A/V Edge Server

Because the host's internal IP and the two NAT-compatible Edge IPs are in the same subnet, then Windows Server will allow them to be bound to the same physical interface. The router that NIC #1 is plugged into was configured to route traffic to/from 10.1.1.10 back to the internal firewall, but route traffic for the other .11 and .12 addresses to the external firewall which was set to NAT both behind dedicated public IP addresses. The second interface would be connected to a dedicated port on the external firewall appliance and traffic would be routed without any address translation directly to the Edge Server.

After deployment and configuration of the Edge Access role I was having problems getting external clients to successfully login to OCS. I rechecked the configuration and all the settings were correct, the certificates were assigned and working, and there were no IP routing issues. I could telnet to both ports 443 and 5061 on both the Edge and Front-End servers from any location on either side of both firewalls. Using performance monitor on the Edge server I could see the inbound connections coming in from the external clients, but the connection was failing to make the next-hop to the internal pool. The complete lack of errors or warnings in the event log didn't help much either.

The next morning my client notified me that the additional dual-port NIC had arrived and was installed, so I went about reconfiguring the network utilizing a third interface:

NIC #1

10.1.1.10 - Host

NIC #2

12.1.2.34 - A/V Edge Server

NIC #3

10.1.1.11 - Access Edge Server

10.1.1.12 - Web Conferencing Edge Server

At this point Office Communicator on the external test client connected immediately. So even though my internal and external IP addresses are on the same subnet and both interfaces connect back to the same router, OCS apparently requires separate physical interfaces or will just not function correctly.

Theoretically the first configuration should have worked, but I originally had my reservations about whether OCS would not like the internal and external route sharing the same physical interface, even though I saw no connectivity problems between the Edge and Front-End servers over various ports.

Category: Office Communications Server

Published: 11/9/2007 10:31 AM

Categories: Office Communications Server

Enabling Custom Phone Number Normalization with the Address Book Service

Jeff Schertz — Sat, 17 Nov 2007 17:38:28 GMT

Body:

The current Office Communications Server 2007 documentation doesn't go into very much detail regarding the configuration and behavior of Phone Normalization in the Address Book Service. I won't be going into any details regarding customization of normalization rules and how they operate, as the purpose of this blog entry is just to understand how to enable this feature and how to force OCS to load the changes.

I have found some details in the LCS 2005 Address Book Service Planning and Deployment Guide, but there are some changes in OCS 2007. Mainly, LCS uses a pair of configuration files which are installed by default:

Generic_Phone_Number_Normalization_Rules.txt
Sample_Company_Phone_Number_Normalization_Rules.txt

But after installing OCS 2007 you will find that only the Sample file exists, and not the Generic file. I have yet to confirm this, but my suspicion is that these rules are no longer stored in a read-only text file but have been integrated directly into the service.

Executing the abserver -dumpRules command will display the built-in rules for verification. (The executable abserver.exe is located in the \Server\Core subdirectory of the OCS installation folder.)

In order to create and activate any custom rules you'll need to create a new file in the proper location, rebuild the address book file, and manually force a Communicator client to download the updated file from the front-end server. (The default OCS configuration resynchronizes the address book at 1:30AM local time each day.)

Step 1

Find the current location of the Address Book Server files by clicking on the Standard Edition Server or Enterprise Pool and expanding the Address Book Server Settings in the Office Communications Server 2007 management console.

The default location on the Standard Edition Server in my lab is:

But an Enterprise Edition deployment creates shared folders for the Address Book and Meeting information, so a UNC path may be shown instead:

Step 2

Create a new text file with the name "Company_Phone_Number_Normalization_Rules.txt" and configure the desired normalization rules.

Step 3

Execute the command abserver -regenUR to trigger the User Replicator regeneration process.

C:\Program Files\Microsoft Office Communications Server 2007\Server\Core>abserver -regenUR
Triggering UR regenerate - successful.
You might have to wait up to 5 minutes for it to actually complete.

Monitor the Office Communications Server event log for events in category 1009 and source OCS User Replicator:

Event Type: Information
Event Source: OCS User Replicator
Event Category: 1009

Event ID: 30027
Description: User Replicator has started initial synchronization...

Event ID: 30024
Description: User Replicator has completed initial synchronization...

Event ID: 30028
Description: Address book (AB) entries are populated successfully...

Step 4

After seeing Event ID 30028 confirming completion, execute the command abserver -syncNow to trigger a new Address Book Server synchronization pass.

C:\Program Files\Microsoft Office Communications Server 2007\Server\Core>abserver -syncNow
Triggering Address Book Server synchronization pass - successful.
You might have to wait up to 5 minutes for it to actually complete.

Monitor the Office Communications Server event log for events in category 1008 and source OCS Address Book Server:

Event Type: Information
Event Source: OCS Address Book Server
Event Category: 1008

Event ID: 21005
Description: Synchronization pass started.

Event ID: 21034
Description: One or more phone numbers failed to normalize.

Event ID: 21007
Description: Synchronization pass completed successfully.

Event ID: 21056
Description: Synchronization Pass Summary.

Event ID: 21058
Description: Synchronization Pass Summary for Device Address Book files

Event ID: 21004
Description: Next synchronization pass will start at: 11/17/2007 1:30 AM

Once synchronization has finished you can test any custom normalization rules using the command abserver -testPhoneNorm.

Step 5

On a workstation running Office Communicator 2.0 make sure to sign-out and exit the client.

Remove the local copy of the Address Book by deleting the file %USERPROFILE%\Local Settings\Application Data\Microsoft\Communicator\GalContacts.db.

Restart the OC client and sign-in. The updated address book should now be enabled for the client.

Update:

I recently discovered where the normalization information is kept on the client. It's not stored in the GalContacts.db, but in the registry. So if you are updating changes for Communicator and not necessarily making changes to the Address Book, then the last step above may not be required. Simply restarting the Communicator client should read-in the updated value:

Key: HKEY_CURRENT_USER\Software\Microsoft\Communicator\

Value: PhoneNumberNormalizationRules

Type: REG_SZ

Update 2:

After further testing I've discovered that the initial abserver -regenUR command is not required when trying to update changes to the normalization file. Also, the Communicator client is programmed to automatically update the galcontacts.db file each time the application is launched, so simply exiting and restarting without manually deleting the file seems to also pick up changes in the address book.

Category: Office Communications Server

Published: 11/17/2007 12:11 PM

Categories: Office Communications Server

Managed Folder Mailbox Policies Tips

Jeff Schertz — Sun, 18 Nov 2007 17:09:23 GMT

Body:

Here's something I've run across a couple times while helping clients configure Exchange 2007, as well getting it wrong the first time I set it up in my test lab. If you are trying unsuccessfully to use the new Managed Folder Mailbox Policy feature in Exchange 2007 to move items from default folders into a new Managed Custom Folder there are a couple important steps worth verifying.

As an example I performed the following steps:

Created a new Managed Custom Folder named System Cleanup.

Configured Managed Content Settings on the default Inbox folder to identify items older than 7 days and move them into the System Cleanup folder.

I then created and configured a Managed Folder Mailbox Policy and applied it to a couple test mailboxes.

If you have performed similar steps but either (1) the new Custom Managed Folder is not appearing in your associated user's mailboxes, or (2) the folder appears but no items are getting moved into it, then let's check a couple important configuration steps that can be easily over looked or misunderstood.

(1) Was the Managed Folder Assistant Scheduled?

First, make sure that you've enabled and scheduled the Managed Folder Assistant under Messaging Records Management in the Mailbox Server Configuration.

Now instead of waiting until the next scheduled time for the assistant to run, just kick-off a new process using the following cmdlet:

Start-ManagedFolderAssistant

Check the Application event log for confirmation that the process started and completed.

Event Type: Information

Event Source: MSExchange Assistants

Event Category: Assistants

Event ID: 9021

Description:

Service MSExchangeMailboxAssistants. Managed Folder Mailbox Assistant for database First Storage Group/Mailbox Database (3b4042c3-296b-40e3-9e7b-7a17a000132e) is processing an on-demand request. There are 2 mailboxes to process.

Event Type: Information

Event Source: MSExchange Assistants

Event Category: Assistants

Event ID: 9022

Description:

Service MSExchangeMailboxAssistants. Managed Folder Mailbox Assistant for database First Storage Group/Mailbox Database (3b4042c3-296b-40e3-9e7b-7a17a000132e) has finished an on-demand request. 2 out of 2 mailboxes were successfully processed. 0 mailboxes were skipped due to errors.

Open the test user's mailbox and verify that the Managed Custom Folder now appears and is populated with any moved items.

(2) Was the Managed Folder Mailbox Policy correctly configured?

Here's where I messed up the first time configuring this in my lab as I had everything shown above set correctly, but was not getting any items old items pulled out of the Inbox and moved into System Cleanup. After some research and retracing of my steps I realized that I had not correctly associated all managed folders with the policy.

Originally I only added the new custom folder, thinking that was all that was required. The folder did appear in the user's mailbox, but was empty even after multiple scheduled and on-demand requests had processed.

But what you need to do is associate all managed folders in the policy, both the target custom folder(s) and the default (and any custom) source folders which contain any Managed Content Settings you want applied, so I added the Inbox folder to the mailbox policy.

After making the change above and forcing the Managed Folder Assistant to run I checked my test mailbox to find that everything was now working correctly and some old messages had be moved into System Cleanup.

It makes sense now that I understand the process, as you need to tell the specific policy which existing Managed Content Settings to use, as just creating a folder policy doesn't mean Exchange will execute those rules. This level of control offers the ability to setup different sets of rules and apply them to different mailboxes.

Category: Exchange Server

Published: 11/18/2007 11:27 AM

Categories: Exchange Server

OCS Edge Server Configuration Topologies

Jeff Schertz — Thu, 29 Nov 2007 04:40:43 GMT

Body:

Although deploying Office Communications Server 2007 for use internally is quite straight-forward, things begin to get complicated when adding in the components used for external client connectivity. The most misunderstood portions of deployment seem to be the correct configuration of the reverse proxy, and the networking configuration of the Edge Server itself.

OCS Edge Server Configuration

The Edge Server Deployment guide covers a variety of support topologies but the Consolidated Edge Topology is probably the most common, yet least understood. When deploying a single Edge Server role into a test, pilot or production environment it is important to correctly design and configure the networking component of the Windows Server before installing OCS. I've seen both first-hand and online many scenarios where an attempt to stray, even slightly, from the recommended deployment parameters can cause major communications problems across the board.

IP Addressing

Most importantly the deployment guide recommends that a different IP address should be assigned to each server role. Unless you enjoy spending an inordinate amount of time reading through tracing logs or troubleshooting strange connectivity errors I suggest you heed this advice. Yes, you can modify default ports for separate OCS communications and pile-on services into a single-IP address, but why? Unless there is some major limiting factor in your specific environment or Santa only gave one IP address to you for Christmas, save yourself some grief and stick to the recommendations as best as you can.

I suggest closely reading Step 1.2 in the OCS 2007 Edge Server Deployment Guide describing the deployment topology. Each of the bulleted items should be fully understood before moving forward. Also, page 102 in the OCS 2007 Planning Guide goes into some detail about the specific requirement of a Public IP address assigned directly to a physical interface on the Edge Server. This is not simply a 'recommendation' and has been documented in multiple blogs and forum discussions.

Network Interfaces

The same logic applies to the assignment of network interface cards and IP subnets as well. The absolute bare minimum number of NICs on an Edge Server is two. All of the best practice recommendations throughout the deployment guides define an internal and external interface for a server deployed in a perimeter network between 2 firewalls, an external perimeter firewall and internal perimeter firewall:

The diagram below outlines this topology along with the often misunderstood Reverse Proxy rule which is shown on a completely seperate physical server than the Edge Server:

But since only one public IP addresses is required for the A/V role, and not for the Access Edge or Web Conferencing roles, an additional network interface can be added to the Edge Server to Route to the public IP and NAT the two private IP addresses. If an the external firewall does not have dedicated ports for routing traffic then this configuration can allow for only the A/V Server interface to be connected outside the firewall and not all three Edge Server roles. This is a less secure approach but many smaller environments may not have the ability to directly route public IP addresses through the firewall and will need to connect to the Edge Server directly to the Internet; this configuration can help reduce the attack surface.

One final note I'd like to add about the configuration above is that in a server-class system it's routine to have a couple dual-port network interface cards so using all four interfaces is probably best from a performance standpoint, as well as potentially side-stepping any other undocumented problems that might arise from services sharing an interface. There are many possible configurations in even a consolidated topology, but it seems that the more resources (both physical and virtual) which can be dedicated to the Edge server, the better.

3-Leg Perimeter (DMZ) Configuration

Let's say for the sake of argument you have a simpler design of a DMZ network 'hanging' off of a single firewall appliance or ISA server in a 3-Leg configuration and you want to deploy a consolidated OCS Edge server with a single interface. On paper this would appear to be possible if assigning IP addresses to the Internal Interface and Access Edge Server in the same subnet and then use NAT on the firewall to publish the Access Edge IP address. Well, I tried this in a pilot rollout and had connectivity working in Windows Server 2003 for all required traffic but OCS would simply fail to correctly pass connections from external client onto the internal Front-End server(s). So the second important lesson is that the Edge Server must have separate Internal and External interfaces.

Given these parameters, here are two choices for valid configurations which are driven by the IP subnet used in the current perimeter network:

Perimeter Network uses Private IP Addresses

ISA Server Network Relationships
1. NAT relationship between the External and Perimeter Networks
2. Route relationship between the Internal and Perimeter Networks
3. NAT relationship between the Internal and External Networks.

Edge Server Network Interfaces
1. NIC1 (Internal) routed to ISA Server
  1. Assign IP Addresses from existing private subnet
  2. Assign to Edge Internal Interface
1. NIC2 (External Private) routed to ISA Server
  1. Assign two IP Addresses from existing private subnet
  2. Assign to both Access Edge and Edge Web Conferencing
1. NIC3 (External Public) routed to external Firewall Appliance (or Internet)
  1. Assign IP Addresses from public subnet

In this scenario three separate network interfaces are needed on the Edge Server because of two conflicting requirements: (1) the need for separate physical internal and external interfaces, and (2) the use of two different IP subnets between the three external Edge Server roles.

Perimeter Network uses Public IP Addresses

ISA Server Network Relationships
1. Route relationship between the External and Perimeter Networks
2. NAT relationship between the Internal and Perimeter Networks
3. NAT relationship between the Internal and External Networks.

Edge Server Network Interfaces
1. NIC1 (Internal) routed directly to the internal network (bypassing ISA Server)
  1. Assign IP Addresses from existing private subnet
  2. Assign to Edge Internal Interface
1. NIC2 (External) routed to ISA Server
  1. Assign three IP Addresses from existing public subnet
  2. Assign to Access Edge, Edge Web Conferencing, and Edge A/V Servers

If the current Perimeter network uses public IP addresses and 3 addresses can be spared, then a consolidated Edge Server can be deployed with just two interfaces, placing three public IP addresses in the same subnet on the External interface.

Certificates

To take this one-to-one theme a step further, Certificates should also be a dedicated to each service. The deployment guide mentions in a couple spots that the A/V Edge Server does not require a certificate, and wildcard certificates are currently not supported in OCS. Special attention should also be paid to the Subject Alternative Name field of certificates and how OCS uses that information, and how ISA doesn't!

Below is an outline of how the certificates can be deployed:

Edge Server
- Internal Interface
  - Issued by internal Windows Enterprise CA
  - Subject Name is the server's FQDN (e.g. ocsedge.internal.contoso.com)
- Access Edge Server
  - Issued by trusted third-party certificate authority
  - Subject Name is the FQDN used by the client to connect (e.g. sip.contoso.com)
- Web Conferencing Edge Server
  - Issued by trusted third-party certificate authority
  - Subject Name is unique FQDN (e.g. webconf.contoso.com)
- A/V Authentication Edge Server
  - Issued by either internal Windows Enterprise CA (recommended) or trusted third-party certificate authority
  - Subject Name is unique FQDN (e.g. av.contoso.com)

ISA Server Reverse Proxy
- Internal Communications (OCS to ISA)
  - Issued by internal Windows Enterprise CA during Front-End deployment
  - Subject Name is the server's FQDN (e.g. ocsfe1.internal.contoso.com)
- External Communications (ISA to external client)
  - Issued by trusted third-party certificate authority
  - Subject Name is the external Web Farm FQDN (e.g. abs.contoso.com)

OCS Reverse Proxy with ISA 2006

Using ISA Server 2006 we need to create a publish a web site rule to allow external clients access to address book and meeting information which is hosted on the internal Standard or Enterprise server via the IIS Default Web Site. Following the instructions under section 2.1 of the Edge deployment guide can be a little tricky at first, but makes much more sense once a few specifics are more clearly understood.

The paragraph below is very confusing as it's actually referring to two different certificates but reads like they are talking about just one:

Request and Configure a Certificate for Your Reverse HTTP Proxy

The root certification authority (CA) certificate for the CA that issued the server certificate on the Web server (the IIS server running your Office Communications Server Web components) needs to be installed on the server running ISA Server 2006. This certificate should match the published FQDN of the external Web farm where you are hosting meeting content and Address Book files.

The first statement basically says that you need to export the root CA certificate from your internal CA and import it into the Trusted Root Certification Authorities store on the ISA computer; simple enough. But the second sentence is now talking about a second certificate that should be requested from a third-party CA and will be used by external clients to connect to ISA via the published External Web Farm FQDN. What this 'Web Farm" FQDN actually refers to is the external name that clients will use to connect to the IIS web site which is running on the internal OCS front-end server. This is NOT the FQDN used by clients to connect to the Access Edge, A/V service, or Web Conferencing service. In this example I will use abs.domain.com as the external FQDN, which will be configured in the OCS Edge deployment wizard and is part of the in-band configuration information to is passed to the external client once it makes a connection to the Access Edge service.

So to summarize that, the internally issued certificate which is assigned to the Front-End server's default web site will be trusted by the ISA Server, and a second third-party certificate needs to be installed on the ISA Server in order to assign to the web listener for the external client to accept. ISA will terminate the connection from the requesting external client using one certificate and then create a second connection (using the other certificate) to the internal web site, essentially bridging the entire connection.

And if it's not completely clear by looking at the first diagram in this article, then let me restate the obvious: the Reverse Proxy is not configured on the Edge Server itself, it's simply a way to allow external users access to a web site running on the internal OCS server. Installing ISA on the Edge Server for this rule is not advisable (and probably not even possible; I can't imagine even attempting to host both ISA and OCS on the same physical server!)

Once these important points are understood then working through the rest of the deployment guide should be pretty straight-forward. The resulting ISA publishing rule and web listener configuration would look something like this:

Update: Microsoft has recently released a white paper on how to design a perimeter network with OCS 2007 in mind. I haven't had a chance to read the entire document yet but it includes a number of scenarios with detailed diagrams and IP addressing examples.

Category: Office Communications Server

Published: 11/28/2007 10:57 PM

Categories: Office Communications Server

Controlling the msRTCSIP-OptionFlags attribute for OCS

Jeff Schertz — Sat, 22 Dec 2007 15:38:59 GMT

Body:

When configuring OCS user settings in bulk there are a limited numbers of options one can change when using the Office Communications Server 2007 Management Console. A range of user accounts can be selected and some options can be enabled/disabled like: Enhanced Presence, Federation, External access, PIC, and archival behavior. You can also set EV and meeting policies, but unfortunately cannot control any of the Telephony user settings.

When migrating users and simultaneously deploying new services like Remote Call Control or Enterprise Voice you'll need to directly modify those user attributes in Active Directory. Let's use the example of migrating a few thousand users from LCS 2005 to a OCS 2007 deployment, leveraging Remote Call Control (RCC) with a popular IP-PBX system.

In order to configure RCC for a user there are three AD attributes which will need to be updated: msRTCSIP-LineServer, msRTCSIP-Line, and msRTCSIP-OptionFlags. The image below shows the desired settings for an RCC-enabled user and the related attribute names.

Updating the Server URI and Line URI fields is a straight-forward process, as the associated attributes can simply be modified in bulk using LDIFDE or ADModify.NET. But getting that radio button selected for "Enable Remote call control" is a bit more complicated, as the msRTCSIP-OptionFlags attribute is a bit-mask value where multiple options are represented by a unique bit so that a single attribute can control many separate settings. Think of it as a bank of switches (11 to be exact) in which each 'switch' controls a different user setting and has it's own unique value. The total number of switches is added-up to yield the attribute's value, as can be seen in ADSIedit.

The table below lists each 'switch' and what user setting it controls:

Value	Controlled Behavior	Setting Location
1	Enabled for Public IM Connectivity	User Options > Federation: - Enable public IM connectivity
2	Reserved
4	Reserved
8	Reserved
16	Remote Call Control (RCC) Enabled	User Options > Telephony: - Enable Remote call control
32	Unused
64	AllowOrganizeMeetingWithAnonymousParticipants	Communications > Meetings: - Allow anonymous participants
128	UCEnabled	User Options > Telephony: - Enable Enterprise Voice
256	EnabledForEnhancedPresence	User Options: - Enable Enhanced Presence
512	RemoteCallControlDualMode	User Options > Telephony: - Enable Enterprise Voice - Enable PBX integration
1024	Enabled auto-attendant

If we take a look at the user account in this example using ADSIedit we can see the raw integer value for msRTCSIP-OptionFlags:

That value of 337 tells us exactly which options are currently enabled for this example account: Enhanced Presence (256) + Allow Anonymous Meeting Participants (64) + RCC Enabled (16) + PIC Enabled (1) = 337.

So, in order to correctly update these settings for many users in bulk it's important to export the current value of this attribute for all in-scope user accounts, then increment the integer by adding the value(s) for the desired setting(s), and simply updating that attribute. There are already numerous sources of information on how to import and export AD attributes value, but routine I used was to export the current data from AD using CSVDE, imported it into Excel and used various VLOOKUP formulas to build the new attribute values by reconciling against exports of employee phone directories to gather the needed phone extension. I then saved the new information as a CSV file which looks like this:

DN,msRTCSIP-OptionFlags,msRTCSIP-LineServer,msRTCSIP-Line
"CN=Schertz\, Jeff D,OU=Chicago,OU=All Users,DC=Schertz,DC=local",337,sip:jschertz@cupserver.schertz.local,tel:3932;phone-context=dialstring

(Tip #1: if there are commas in the user object's CN then CSVDE will export them with two backslashes preceding the "," character. Make sure you perform a Find/Replace in Excel to change all instances of "\\," to "\," as LDIFDE requires a single \ character. Having two backslashes before the comma in the import file will cause the process to fail with an invalid DN error. When importing data with CSVDE, two \\ escape characters are required.)

Once I had my import data created I used a co-worker's blog entry as a guide to build a template to convert the CSV file created in Excel into a proper LDIF import file. Here's the contents of my custom csv-ldif.txt template file that matches my CSV file data:

<LPBODY>
dn: %FIELD_3%
changetype: modify
replace: msRTCSIP-OptionFlags
msRTCSIP-OptionFlags: %FIELD_4%
-
replace: msRTCSIP-LineServer
msRTCSIP-LineServer: %FIELD_5%
-
replace: msRTCSIP-Line
msRTCSIP-Line: %FIELD_6%
-
</LPBODY>

By following Derek's directions you can use the Microsoft Log Parser utility to convert the standard CSV file into a properly formatted LDIF file which will update all three attributes for each user in turn.

In this specific deployment most of the current LCS 2005 users had a msRTCSIP-OptionFlags value or either 0 or 1 (only a handful of users had PIC enabled) so I simply incremented the values to 16 and 17, respectively. This enabled RCC for all users as the accounts were simultaneously moved to the new OCS server. As the client workstation's will next be upgraded to Office Communicator 2007 (and Enhanced Presence enabled) Remote Call Control will immediately be available.

(Tip #2: Be careful when incrementing the value as if it's increased by 256, then Enhanced Presence will be enabled, which cannot be reverted.)

Category: Office Communications Server

Published: 12/22/2007 9:38 AM

Categories: Office Communications Server

Attachments: http://blogs.pointbridge.com/Blogs/schertz_jeff/Lists/Posts/Attachments/20/image_2.png
http://blogs.pointbridge.com/Blogs/schertz_jeff/Lists/Posts/Attachments/20/image_thumb.png
http://blogs.pointbridge.com/Blogs/schertz_jeff/Lists/Posts/Attachments/20/ocs_optionflags1_2.png
http://blogs.pointbridge.com/Blogs/schertz_jeff/Lists/Posts/Attachments/20/ocs_optionflags1_6.png
http://blogs.pointbridge.com/Blogs/schertz_jeff/Lists/Posts/Attachments/20/ocs_optionflags1_thumb.png
http://blogs.pointbridge.com/Blogs/schertz_jeff/Lists/Posts/Attachments/20/ocs_optionflags1_thumb_2.png
http://blogs.pointbridge.com/Blogs/schertz_jeff/Lists/Posts/Attachments/20/ocs_optionflags2_2.png
http://blogs.pointbridge.com/Blogs/schertz_jeff/Lists/Posts/Attachments/20/ocs_optionflags2_thumb.png

Live Meeting 2007 Client Download

Jeff Schertz — Wed, 30 Jan 2008 20:08:04 GMT

Body:

Just a quick blog entry here; it seems like every time I need to send another external party the link to download the LM2007 installation, I can never find it. Yes, the link itself is in the invitation email (although somewhat difficult to find) but those aren't always handy when trying to create an impromptu conference with external IM attendees who are not already running OCS and/or LM 2007 themselves.

So here is the link to the download page:

http://office.microsoft.com/en-us/help/HA101733831033.aspx

Just click the Accept and Install Client link in order to download the 16MB package.

Also, here’s the link to the Outlook Add-In component, in which the “Meet Now” option has returned.

http://office.microsoft.com/en-us/help/HA102368901033.aspx

Category: Office Communications Server

Published: 1/30/2008 2:08 PM

Categories: Office Communications Server

Attachments: http://blogs.pointbridge.com/Blogs/schertz_jeff/Lists/Posts/Attachments/21/image_2_253BC637.png
http://blogs.pointbridge.com/Blogs/schertz_jeff/Lists/Posts/Attachments/21/image_thumb_253BC637.png