Director Role in LCS & OCS (Part 3 of 3)

Now that we have discussed what the director role is and what topologies are available to us, let’s take a look at once the director is in place within our organization. What we chat about in today's blog is now that you have the director in place what happens if you had to stop services on that server for a possible SPIM attack was taking place. Or we can even say that for what ever reason the director server is not responsible. So let’s take a look at the setup that we have for you today....


 We have in our environment, a simple setup with three servers; we have a "Collocated Edge Server", "Director", and a "Standard Edition Server".

In our configuration we concentrate on the config of the Director server; for our internal sample deployment we are using Automatic Configuration. What that does is enable the users in the organization to sign-in automatically with DNS and not have to manually set server names within communicator. By using automatic configuration we are leveraging DNS records to find the director and home server.

So what are the settings that we are going to need? Well, to start out with, we will need to have a SRV records and "A" host records. The servers that we will be using for this deployment are as followed:

Edge -

Director -

Standard Edition Server -

Now lets take a look at the flow of internal authentication within our organization; as users sign-in to communicator that are connected to the director server which does the user authentication which then passes on request to the Standard Edition server which is our home server.

The DNS records that we have in place are which points to We also have an "A" host record that points to the director server. In addition we have an "A" host record for as well.

So now we have a setup of automatic configuration where all the internal users are looking at the director server ( for authentication which then sends people to the Standard Edition ( server for IM communication.

Now for that unforeseen disaster that happens...We have a DoS attack and we have to shut down the director server to stop from passing it on to our internal organization. A way to do this would be to stop the services on the director server. With stop the services, we block outside communication from coming in, in addition we have to be careful because we have setup our internal automatic configuration to point to the director too. So by just stopping the services this makes the server unresponsive and users will not be able to authenticate to the internal OCS organization. When a user sign's out and attempts to sign-in they will not be successful.

To make life grand again, we need to make some DNS changes; when need to find the DNS "SRV" record that specifies and open the record and modify the space that states "FQDN of server" and point to our Standard Edition Server which is By doing this you have just redirected authentication from pointing to your director to now point the actual home server.

There are a couple of things that should take place now are those are DNS replicating and restarting the Standard Edition Server. Now that you have done this, users might have to a DNS\Flush on their side, but other than that, they should be good to go, users are now able to leverage automatic configuration once again despite the director server being offline for the time being.

 Keep in mind that once you enable services on the director server again and route traffic back through this server that you will have to undo the DNS changes that you just made back to the original settings.

 This concludes our three part series of the director role in OCS 2007, for a recap we covered the following:

1) Why do I need a director server?

2) Topologies of a director

3) Now that I have a director in place