As we all know, keeping your servers updated can be a tedious job.  As Exchange and OCS deployments grow in size and complexity, the judicious administrator will deploy more automation tools to minimize those tasks that can be managed automatically.  One of the tasks is the onerous job of keeping servers and systems updated to ensure security and functionality.

In part one of this series, I showed how to do the simple method - subscribing the OCS host server to Microsoft Update so that the server could get the OCS updates that are published from time to time as well as the operating system updates that come out monthly. This same process is used to subscribe the various Exchange server roles.  In this post, I will show you how to configure WSUS (Windows Server Update Services) to accomplish the same tasks. In fact, it also works for SQL, SharePoint, Project Server, and any other Windows operating system I can think of (well, not PXE or Mobile, but you get the idea). If you already have WSUS  deployed, excellent, then you only need part of this post to accomplish your goals.  However, believe it or not, there are folks out there (maybe they are new to all of this) that don’t have this valuable tool deployed in their organization - these folks will want to read all of this post.  One of the benefits of WSUS for the smaller organizations is that all that update traffic only has to cross your WAN link one time - thereby creating a situation where you have helped optimize your network without incurring any fees.

First off, you need to have WSUS installed.  Once you have that done, you need to configure a Group Policy to apply to servers, and maybe your workstations, so that you can control the update distribution and application process.  After the GPO is created and applied, then you need to jigger a few settings inside of WSUS and exercise a bit of patience, and you will have an operational patch deployment system for your OCS deployment.  Keep in mind that this same WSUS deployment can be used across your organization to deploy patches to operating systems, servers (like Exchange, SQL, OCS, etc), and workstations (keep that Office install updated!).  I will cover only the OCS aspects, but I will also demonstrate Exchange 2007.  So, the overall process is as follows:

1. Install WSUS
2. GPO work
3. Configure WSUS
4. Relax while everything catches up.

To get started, get a copy of WSUS. Install it on a server that is a member of your domain. You can have non-domain members point to a domain WSUS server, but i will not cover that here.  For my lab, I installed WSUS on an x86 WS03 R2 SP2 server.  WSUS needs IIS, so make sure you plan for that.  WSUS works just fine from virtual - make sure that you give the VM a good 30GB to allow for the downloads of patches and updates.  Sometimes the service packs that get downloaded get a tad sizeable - you will want some breathing room. 

Did I mention breathing room?  this is what my WSUS server is downloading…and I have an abbreviated update scenario…

My VM is running on 512MB of RAM, and I have tested operations as low as 192MB - response gets a tad slow, but the overall function of the WSUS is not materially affected.  Out of scope for this blog is how to actually install WSUS; even I have space limitations!

Once you get WSUS installed, you need to configure the following items.  Fear not, most of these are pretty straightforward, and not all of them need any changing for a basic installation.  The install itself will invoke the wizard that is the bottom option, and just working through that will connect you, enable downloading of updates, patches, and service packs.  I have mine running out through my standard ISA 2006 firewall.  Because my firewall allows all internal traffic outbound, I had no connection issues.

The important part to us in this blog is the “Products and Classifications” selection.

Here you can see where I have chosen to keep my Exchange 2007 organization updated.

Here are the OCS specific selections.  Note that the Office Communicator 2007 is also listed.  Choosing this option will allow you to keep those client workstations updated without having to figure out how to push MSP files out to workstations.

Now that we have WSUS installed, and configured at the basic level, let’s turn to the GPO aspects of this project.  I will discuss this work as based on a WS08 domain controller. If you have WS03 domain controllers, the details of “how to” will be a bit different, but nothing serious.

First, access the Group Policy Management applet.

In my case, I only have one policy.  I do everything out of the default domain policy as I have a fairly simple setup.  Open that policy for editing.

The GPO has two sections, computer and user.  We want to configure settings in the Computer Configuration section.  Expand Policies | Administrative Templates | Windows Components and then look all the way down at the bottom.  Most likely, you will have to scroll down to find “Windows Update.”

There are quite a few options.  You will need to configure them for your specific environment.  We are most concerned with the following: 

1. Configure Automatic Updates (I set mine to three - you will most likely want setting four)
2. Specify intranet Microsoft update service location Properties (mine is set to http://WSUS
3. Automatic Updates detection frequency
4. Allow non-administrators to receive update notification
5. No auto-restart with logged on users for schedule automatic updates installations
6. Enable client-side targeting (bingo!)

This last one is where you get to play a bit - I segregate by servers and workstations.  I want workstations to install and don’t ask questions.  I want servers to download and then prompt me for what I want to install.  While this works for the lab environment, it may not work for you.  However, if you want something like this, you will need to enter some group names here, and the names need to match what we’ll put into WSUS in the next step.

Here are my entries for the last property.

When you get done, just close up the editor.  GPO settings are  saved behind your back, and on the next update cycle, the entire domain will get the change to Windows Update.  If you don’t want this behavior, you will need to go through the process of creating a separate GPO, linking it to containers, domains, etc, until you get the configuration that suits your purposes.  By default, in a WS08 domain, the workstations will update themselves every 90 minutes with a random offset of 30 minutes.  Or, you can go to each server and workstation and do a “gpudate /force” - me?  I did this work and then went to lunch.  When I came back, all machines in my domain were updated and ready to move onto the next step.

OK, back to the WSUS server, and let’s assign computers to groups, and configure the groups and approvals.

Configuring groups is easy…click on the indicated spot, and create some groups that represent your organization and how you intend to administer updates.  Again, in my case, “servers” and “workstations” are the only two I need.

To assign the computers to groups, refresh your view or exhibit the aforementioned patience.

Here you can see my domain member servers as unassigned.  Select one or more, then right-click to bring up the following dialogue.

In this case, I selected “servers” and clicked on OK.

Now all my servers that have reported in are in the Servers group.

What do these group do for me?  Well, they control how you apply your updates!  Seems pretty simple after you get done, but it is a perfectly logical question.  Good for you for asking it! Over in the Options node, there is this Automatic Approvals wizard…I have two rules, one for the Workstation group, and one for the Servers group. I always remove the default rule, and create my own.  If you have used rules in Outlook, you will have no issues creating and applying the rules here.

Let’s approve some updates, shall we?

The approval process is a matter of you reviewing what is there, approving or disapproving or declining, etc.  For instance, I don’t ever let the automatic update routines download drivers - I have seen too many issues with drivers and automatic updates.  But to the point, look what is in my synchronized, local update store!

The first time you go through the approval process will be a tad tedious, but after that, a short weekly session should be all it takes to keep your servers and workstations updated.  When the computers check into the WSUS, the computer reports in and catalogs itself just like it was communicating with the Microsoft Update site and pulls down only what it needs provided you have approved the update.  Should the update need a reboot, your GPO will control that - which is why I have my GPO set to “3” so servers do not boot themselves at the end of an update cycle.  Your domain needs, of course, will differ from my simple lab.

Now that you have your Exchange and OCS patching automated to a large degree, enjoy some time off for research tasks, keeping your service customers happy, and maybe having a weekend off!

Certificates can be complicated to understand, difficult to manage, and if you don’t have an internal PKI structure, downright expensive as you move forward with more and more dynamic applications that extend Unified Communications to your remote users and business partners.

Internal certificates work wonders for your Active Directory Domain Services members. For Unified Communications, where OCS and Exchange are going to be using the same ISA 2006 server as the firewall, utilizing a Subject Alternative Name (SAN) certificate for your edge configuration and your ISA configuration can save you time, management hassles, and possibly provide cost savings as well. For internal servers, an internal PKI is just fine, but for the public interface of your system, you should most likely be looking at using a public-sourced key such as Go-Daddy, Thawte, DigiCert, etc. OCS Federation, remote users, and Public Instant Messaging Connectivity (PIC) demand public certificates. I know that I do not want to ship my internal CA root certificate to a slew of administrators and expect them to get that certificate into the correct spot for our systems to co-exist. But I digress.

The following table shows the SAN names needed on a certificate to support the base OCS and Exchange functions on ISA 2006 – and I imagine that this certificate construction will work just fine on many other firewalls as well. The table comes from my test domain; you should replace my test domain with your own domain name.

Obtain a public SAN (UCC) certificate from your favorite provider, import the certificate into your OCS Edge server and your ISA server computer account Trusted Root Certificate store and then you can use one certificate for all these uses. This approach leaves you with only the one certificate to manage and renew, or, if life treats you badly, move to a new server.

I get asked, or I hear this question, repeatedly. Clearly, this is a function that needs implementing in almost every organization. I use option 1 (read below). There have been times when I created several of these - it makes admin a lot easier if you have many subnets or individual IP addresses to include.

(this material is not my creation, I am merely posting this)

From time to time, you need to allow an application server to relay off of your Exchange server. You might need to do this if you have a SharePoint, a CRM application like Dynamics, or a web site that sends emails to your employees or customers.

You might need to do this if you are getting the SMTP error message “550 5.7.1 Unable to relay”

The top rule is that you want to keep relay restricted as tightly as possible, even on servers that are not connected to the Internet. Usually this is done with authentication and/or restricting by IP address. Exchange 2003 provides the following relay restrictions on the SMTP VS:

Here are the equivalent options for how to configure this in Exchange 2007.

Allow all computers which successfully authenticate to relay, regardless of the list above

Like its predecessor, Exchange 2007 is configured to accept and relay email from hosts that authenticate by default. Both the “Default” and “Client” receive connectors are configured this way out of the box. Authenticating is the simplest method to submit messages, and preferred in many cases.

The Permissions Group that allows authenticated users to submit and relay is the “ExchangeUsers” group. The permissions that are granted with this permissions group are:

NT AUTHORITY\Authenticated Users {ms-Exch-SMTP-Submit}

NT AUTHORITY\Authenticated Users {ms-Exch-Accept-Headers-Routing}

NT AUTHORITY\Authenticated Users {ms-Exch-Bypass-Anti-Spam}

NT AUTHORITY\Authenticated Users {ms-Exch-SMTP-Accept-Any-Recipient}

The specific ACL that controls relay is the ms-Exch-SMTP-Accept-Any-Recipient.

Only the list below (specify IP address)

This option is for those who cannot authenticate with Exchange. The most common example of this is an application server that needs to be able to relay messages through Exchange.

First, start with a new custom receive connector. You can think of receive connectors as protocol listeners. The closest equivalent to Exchange 2003 is an SMTP Virtual Server. You must create a new one because you will want to scope the remote IP Address(es) that you will allow.

The next screen you must pay particular attention to is the “Remote Network settings”. This is where you will specify the IP ranges of servers that will be allowed to submit mail. You definitely want to restrict this range down as much as you can. In this case, I want my two web servers, 192.168.2.55 & 192.168.2.56 to be allowed to relay.

The next step is to create the connector, and open the properties. Now you have two options, which I will present. The first option will probably be the most common.

Option 1: Make your new scoped connector an Externally Secured connector

This option is the most common option, and preferred in most situations where the application that is submitting will be submitting email to your internal users as well as relaying to the outside world.

Before you can perform this step, it is required that you enable the Exchange Servers permission group. Once in the properties of the new connector, go to the Permissions Groups tab and select Exchange servers.

Next, continue to the authentication mechanisms page and add the “Externally secured” mechanism. What this means is that you have complete trust that the previously designated IP addresses will be trusted by your organization.

Caveat: If you do not perform these two steps in order, the GUI blocks you from continuing.

Do not use this setting lightly. You will be granting several rights including the ability to send on behalf of users in your organization, the ability to ResolveP2 (that is, make it so that the messages appear to be sent from within the organization rather than anonymously), bypass anti-spam, and bypass size limits. The default “Externally Secured” permissions are as follows:

MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Authoritative-Domain}

MS Exchange\Externally Secured Servers {ms-Exch-Bypass-Anti-Spam}

MS Exchange\Externally Secured Servers {ms-Exch-Bypass-Message-Size-Limit}

MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Exch50}

MS Exchange\Externally Secured Servers {ms-Exch-Accept-Headers-Routing}

MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Submit}

MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Any-Recipient}

MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Authentication-Flag}

MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Any-Sender}

Basically you are telling Exchange to ignore internal security checks because you trust these servers. The nice thing about this option is that it is simple and grants the common rights that most people probably want.

Option 2: Grant the relay permission to Anonymous on your new scoped connector

This option grants the minimum amount of required privileges to the submitting application.

Taking the new scoped connector that you created, you have another option. You can simply grant the ms-Exch-SMTP-Accept-Any-Recipient permission to the anonymous account. Do this by first adding the Anonymous Permissions Group to the connector.

This grants the most common permissions to the anonymous account, but it does not grant the relay permission. This step must be done through the Exchange shell:

Get-ReceiveConnector "CRM Application"  | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Recipient"

In addition to being more difficult to complete, this step does not allow the anonymous account to bypass anti-spam, or ResolveP2.

Although it is completely different from the Exchange 2003 way of doing things, hopefully you find the new SMTP permissions model to be sensible.

More information

See the following for more information:

• Receive Connectors
• Exchange 2007 Transport Permissions Model

John Weber
01010101 01101110 01101001 01100110 01111001 00100000 01010011 01110001 01110101 01100001 01110010 01100101