15 March 2012

Address Book Service – Use and Troubleshooting (part 1)

I’ve seen a huge number of issues in the Microsoft public newsgroups related to the Address Book (AB Server). The queries arise from a combination of things: lack of clarity on how the AB Server actually works, bad configuration, permission problems, bad/missing certs, etc. I find we spend a lot of time answering the same questions over and over.
To try to help OCS admins grappling with the AB Server, I’m creating a couple of blog posts on the AB Server. This one, the first, will concentrate on how the ABServer Works. Then in a subsequent post, I’ll look at how to troubleshoot your issues.
Note: What I’m publishing is my understanding thus far. To some degree I regard this blog post as a work in progress – so please comment where I’m wrong, or missing a point. There are some gaps in my knowledge and I’ve indicated where those are. More comments PLEASE! Some of the information comes from the [MS-ABS] information you can find at the Microsoft Office Protocol Documents at: http://msdn.microsoft.com/en-us/library/cc307432.aspx. The rest of it via hard work, and loads of troubleshooting!
What does the AB Service actually do?
The AB Server (and some other components)are a  part of Office Communications Server that provides users with a local address book that can be searched by the client (e.g Microsoft Office Communicator, or MOC, and Microsoft Communicator Phone Edition, aka Tanjay). Clients then get information about OCS related users and groups (distribution lists) stored in AD, but without having to hit AD each time they search.
When it works (which is most of the time), the AB is pretty cool. You can search for users (and DLs) in MOC by just typing letters/numbers. If, for example, you hit “TH”, MOC would show all the entries that begin with “TH” – this would include all the users whose names start with Thomas, Thanthony, ThePowerShellUGDL,etc. The AB also allows clients to do reverse number look-up of incoming VOIP calls. {this is per MS-ABS – need to check of MOC actually does this]
The AB Server system enables searching of the address book using only local resources. But by decoupling the local store from the AD, there is inevitably a degree of imperfectly fast convergence. If I add a new user, Billy Bob Joe Bob for example, it’s not going to be instantly in your local AB even if he can log on pretty quickly. To understand this, let’s look at how the whole AB server process work works.
How Does The AB Process Work?
The AB Process consists of several pieces that  extract information on SIP enabled users and contacts and use this to create a set of files that the MOC client downloads and uses as noted above. At a very high level, this process involves several steps:
  • OCS’s User Replicator service registers for changes in the AD. The UR service then looks at all the new/changed/deleted user or contact objects. The details of these objects are then written to the OCS database. [need to add details around just what the replicator looks for, and where in the DB these records live]
  • The Address Book Server parses the DB contents and produces a set of files that the client can download to generate the local store. The ABServer runs, by default at 01:30 local time, but this can be changed using WMI. The AB Server creates both a new file representing ALL the contact data, plus a set of delta files showing ONLY the changes since a certain number of days ago. These AB files are placed on a local share, which are exposed as an IIS virtual root off the web components server. The ABServer runs on the web components server (and for an expanded Enterprise deployment, on all web components servers.
  • When the MOC client logs on, it obtains the URL to these files via in-band provisioniong. It then loads the appropriate files and creates a local database. This database is stored in [need to add this location]
User Replicator Service
The User Replicator Service has a couple of functions. First,propagates necessary OCS information from AD to OCS relatively quickly. UR can ask AD (technically it asks a GC) for all changes since a certain time. It then writes those changes to OCS’s SQL database. The UR process runs on the Front End Server. [need to add details of process name, and clarify what happens in expanded enterprise deployment]]
The information downloaded enables the OCS (SQL) database to contain all the information about OCS users up to ‘relatively soon  ago’. This means you can add a user and they can logon pretty soon. [need to quantify ‘soon’].
Since OCS has all the information about all the SIP enabled users/contacts, the DB also serves as the basis for generating downloadable address books. This is done by the AB Server that runs on the web components server and the client then downloads these as described below.
AB Server Process
Once a day the AB Server parses the OCS SQL database and creates a set of files that the client can download to construct a local address book database. By default, the AB Server performs this at 01:30 local time. You can use WMI to change this time. [should add WMI class/property to change]
The AB creates several files each night:
  • A full file holding all AB entries (at the time of the AB Server run)
  • Up to 30 delta files, representing the change between “now” and up to 30 days ago.
ABserver produces full files and delta files. Full files contain full details from OCS as of a date. ABServer also produces complete and minimal files that contain more/less information. [need to cite differences between these"]
The delta files contain the difference between two full files including new and changed user objects as well as deleted user and contact objects. The AB Server files are named as follows:
  • F-XXXX.lsabs  - a complete full file from date XXXX
  • D-XXXX-YYYY.lsabs – a complete delta file representing changes between XXXX and YYYY.
  • F-XXXX.dabs - a minimal full file from date XXXX
  • D-XXXX-YYYY.dabs – a minimal delta file representing changes between XXXX and YYYY.
The dates in these file names are 4-digit hex values representing the 0-based number of days since January 1, 2001, 00:00:00 UTC. Thus  F-0A8C.lsabs would be the address book file for Saturday, May 24, 2008.
The files with the .LSABS extension contain full information about each contact or user. Files with the .DABS extension contain a minimal subset of information useful to a SIP Phone Client. [need to check that MOC downloads the .lsabs and that the tanjay downloads the DABS]
What does the client do?
When the client logs into OCS, the client subscribes to provisioning information. The FE/registrar server responds by sending this information which includes a b base URL details of where to find the AB files. The client then uses the URL to request the appropriate files. It does this by concatenating the base URL received via in band provision with a detailed name based on the current date (using the date format noted above).
If this is the first time the client has ever logged on, or if the client hasn’t logged in for 31 days or more, MOC downloads the latest full file. If the user has logged in between 1 and 30 days ago, MOC downloads the appropriate .LSABS file. If the file is a delta, it’s merged wiuth the current address book. If it’s a full file downloaded, the new file overwrites the older one.
In some cases, the size of the delta can be larger than the size of the full file. This could happen if you do some major re-organisation of the AD (deleting users, adding users, etc). In such cases, no delta is created, and a full file is used instead.
The MOC client gets two separate base URLs – an internal one and an external one. MOC will first try to access the AB Server files using the internal base URL. If that fails (i.e because the client is external), MOC tries again using the external address. [need to confirm this using WS]
So What can go Wrong
In an nutshell – lots. although in most cases it all just works. There are some simple problems to resolve, as well as some more complex ones. But I’m leaving those details for a second blog article that looks into the primary issues you may face. I’ll publish this later this week.

31 October 2009

This blog closing down

This is the last post I will be making in this blog, which is now closing down as I head off for pastures new. It’s been fun to post here but life moves on.

In future, my posts on the subject of OCS are to be found posted to my technical blog: Under The Stairs at http://tfl09.blogspot.com.  I also post PowerShell Scripts to my other blog: PowerShell Scripts Blog at http://pshscripts.blogspot.com. Some existing posts will be left here for a while, but will gradually go or move to my technical blog as appropriate. Eventually I’ll remove this blog, so adjust your short cuts and RSS feeds.

For those of you how have read this blog I thank you and for those who have communicated via this blog double thanks.

As the words in the song go: What a long strange trip it’s been!

04 March 2009

OCS 2007 R2 E-Learning from Microsoft

Microsoft has just released a new E-Learning collection entitled: Collection 10051: Exploring New Features in Microsoft Office Communications Server 2007 R2. This collection “collection” includes two  E-Learning clinics (aka 1-hour modules):

This collection provides a brief overview to what’s new in OCS 2007 R2 and is at around the 150 technical level – it concentrates on the key features of R2 but not dive too deeply. The first clinic looks at what’s new in R2, while the second clinic looks at how you can deploy and migrate to R2.

And a nice feature – these are free.

Technorati Tags: ,,

23 February 2009

Managing OCS 2007 R2 from the Command Line

Greg Stemp and Jean Ross (who use to be The Scripting Guys), have written a good article on TechNet: Office Communications Server: Managing OCS 2007 R2 from the Command Line.

This article looks at how to use LCSCMD to do useful stuff with OCS. As usual with Greg and Jean’s stuff, the writing is good, and examples are most relevant. And for OCS wanabe-gurus, there are a couple of cool  bits of information I’ve not seen elsewhere (application IDs for example). Well worth a read and a bookmark!

However, LCSCmd.Exe is not the only Command Line tool. The (ex) Scripting Guys have forgotten PowerShell! There’s no mention of PowerShell in this article at all, which is a curious omission. Or possibly the by-product of a word count limit on TechNet).

I’ll write more on this soon over on my Technical Blog: Under The Stairs.

Technorati Tags:

22 December 2008

Office Communications Server 2007 R2 is completed

I have it on good authority that Microsoft has completed their work on OCS 2007 R2, which is due for launch in Feb 09.  As of now, it’s not reached MSDN but I’d expect is fairly soon. Allegedly, it’s build 6907. Note that it’s 64-bit only!

Although coming just 18 months after OCS 2007 RTM, R2 is more than just a service pack – it both introduces some cool new features e.g. Attendant Console3, Dial-in Conferencing Support, a much improved CWA and persistent chat to name a few.

I am hoping we’ll see a OCS 2007 R2 Ignite in the new year.

Technorati Tags: ,

04 December 2008

Edge Planning Tool for Office Communications Server 2007

One of the biggest support call generators for OCS 2007 relates to deployment of the Edge Server. OCS’s Edge Server role can be complex to deploy mainly due to the combination of roles, ports, and IP addresses involved. To help you to deploy your Edge, Microsoft have produced the Edge Planning Tool for Office Communications Server 2007. This is a free download!

The Edge Planning tool produces reports you can use to get your Firewall/DNS/etc folks to do the right thing.

A nice tool.

01 December 2008

OCS Voice Ignite – Back on the Road

Technorati tags: , ,

I’m in Paris this week, and plan to be in Bangalore next week on OCS Voice Ignite. This week, I’m attending the updated version of this cool 5-day technical training session. Next week, I’ll be running a Voice Ignite event at Microsoft’s Technology Centre in Bangalore.

I can’t say much about this training, since it’s covered by NDA. But I can say a) it’s pretty cool training with what looks to be good labs and b) it’s a must if you are seriously going to deploy OCS Voice in your enterprise.

If I can get permission, I’ll post more details.

14 November 2008

RampUp – Free Developer Training From Microsoft

If you are a developer, Microsoft has some new free training. Microsoft explains Rampup as: “free, online, community-based learning program, with a number of different tracks that will help you build your portfolio of professional development skills. Ramp Up has a solid foundation of premium technical content from subject-matter gurus, and provides easy-to-access content in a variety of forms that guide you in learning the important skills. Join Ramp Up (it's free!) and help advance your career”

The current offerings and current web site are clearly a work in progress. The site is a little clunky with the integration between MSDN and MS Learning being less than totally seamless. There’s a lack of discoverability, little integration between this training and the MSDN Library content and the material is not bang up to date. But that’s just work that needs to be done – the free training is still of benefit.

I’ve suggested that the next course to go up on the RampUp site should be PowerShell for developers. We’ll see if MS take me up on this suggestion.

So if you’re a developer, why not head on over to the new Ramp Up site and sign up?

Technorati tags: , , ,

04 September 2008

Office Communications Server R2- 64 bit only!

The news is out: Office Communications Server Team Blog - the next release of OCS requires a 64 Bit OS (x64). This decision was made some time ago, but was only externally announced Last Friday (the Friday before Labor day – a great day to bury news).

For OCS this makes a lot of sense. Running on the X64 OS enables significantly more memory to be allocated. There’s also some evidence that says X64 is a more secure platform. However, there are some real downsides. For OCS 2007 customers, there’s no direct or easy upgrade path – you need a new OS install and a fresh install of OCS 2007 R2. And for those of us doing training, etc, there’s the very real downside that you can’t run x64 apps like OCS 2007 R2 in either Virtual PC or Virtual Server. We’ll either have to use Hyper-V (which is not very laptop friendly), or move over to VMware Server/Workstation. Currently, I’m probably leaning towards VMware as it’ll mean I can run OCS R2 on my laptop without requiring an OS Upgrade. Although MS have not said anything in public, I’m hoping there will be a 32-bit version of the product for training, as is the case with Exchange 2007.

MS has also announced shipping of the beta for OCS R2 although as of this morning, it’s not available on TechNet or MSDN. Hopefully this will be out soon.

Technorati tags:

30 August 2008

Authentication Cisco Switch Login using IAS

I’ve been playing around the past couple of days with setting up a Cisco 2960 switch to use MIcrosoft’s IAS (aka Radius) to do authenticate logins based on Active Directory. This has not been all that easy as I’m no Cisco guru (yet) and the Cisco manuals were less then helpful to me.

But after a lot of trial and error, and some googling I managed to get both telnet and SSH to login against Radius. The IAS setup was relatively easy – just add a policy, adjust the profile a bit and Radius authentication could work. Getting the switch setup was a bit more tricky.

Starting from a bare switch (no startup-config), here’s the configuration I used that worked against my IAS box:

! setup fundamental stuff
hostname oslo
ip domain-name gktrain.net
enable password cisco
username tfl password 0 line
!
interface vlan 1
ip address 10.1.1.10 255.255.255.0
! Setup HTTP stuff
ip http server
ip http client username http
ip http client password oslo

! ssh/telnet basic setup
! first – generate keys
! note the key length is on a separate line to enable copy/paste
crypto key generate rsa
512
ip ssh time-out 120
line vty 0 15
transport input telnet ssh
password line
login
! Now Setup Radius to authenticate
aaa new-model
radius-server host 10.1.1.100 auth-port 1812 acct-port 1813 key cisco
! Setup server group for simple addition of more servers
aaa group server radius Radius-Servers
server 10.1.1.100 auth-port 1812 acct-port 1813
aaa authentication login TRAuthlist group Radius-Servers
aaa authentication login  TRAuthlist group Radius-Servers
aaa accounting connection TRAuthlist start-stop group Radius-Servers

line vty 0 15
login authentication TRAuthlist
transport input telnet ssh

That all seems to work relatively well – however I am not seeing any accounting records being sent to the Radius Server, despite the configuration above. I guess that’s a mystery for another day

Technorati Tags: ,,,,,

29 August 2008

More on PowerShell Plus

I wrote about PowerShell Plus on Monday over on my personal blog. I’ve been using it this week to create additional MSDN samples. I have to say that it’s a seriously good product. Like all betas, there are some minor niggles, but the product itself is very much on the right side of very good!

Some features I particularly like:

  • Debugging support – in the script editor, you can set break points easily and intuitively. When at a breakpoint you can get/set variables, etc.
  • Code Signing support – this is nice. You easily select a code signing cert (or generate a self signed cert!) and apply it. PowerShell Plus then signs the script whenever you save.
  • Learning Centre – there is some great info here.
  • History is ‘smart’. You can view history and click on individual lines in the history and have them executed.
  • Intellisense – this is something I find very useful in Visual Studio and it’s equally valuable here!

I first got PowerShell Plus working on my XP Laptop, and today have set it up on my main X64 Windows Server 2008 workstation. It’s not so good on XP, as there are some missing APIs, but on Server 2008 it rocks. I suppose it works well under Vista (i.e. better than on XP), but I do not use Vista here so can’t comment.

All in all, this is an excellent product. When I first saw it and started playing with it, I wasn’t so convinced of the price point. But at US$79.00 (the price for beta testers) I think this is about right.

One niggle over price, it’s actually US$79 plus a US$15.8 “maintenance” charge. Personally, I’d prefer to see a single price (i.e. US$79) and a free update policy for each version. That is, version 2.1, 2.2 upgrades from 2.0 being free, but when Idera bring out a Version 3, then there’s an upgrade cost. They probably make the same amount over time, but it feels a bit dirty to ask for maintenance up front. And if they do need to bundle that extra charge, then why not just charge US$95 for the package and bundle the maintenance for ‘free’.

This is a good product, whether it’s US$79 or US$95! I will probably end up getting the RTM version!!

17 July 2008

Microsoft Office Communicator Auto-discovery Mechanism

It seems to be a day for writing about auto-discovery, the process whereby an application, in this case Microsoft Office Communicator (MOC), can use a limited amount of information to automatically discover the users’s OCS Server. Auto-discovery is based on MOC’s use of DNS resource records to obtain the necessary information. I’ve been reading the formal published specificatin in the absence of bed-time cocoa. Note that this mechanism is used by a MOC client to find an OCS server, and is different from Exchange’s auto-discovery service that enables Outlook to find an Exchange server. The OCS mechanism is simple and easy, while the Exchange service is more complex.

Using auto-discovery, MOC first obtains what the specificatin calls the Address-of-Record, aka the SIP URI. This could be something like sip:tfl@gktrain.net. From the AOR, MOC needs to determine a target domain (the spec just calls this domain). In this case, gktrain.net is the target domain.

The SIP URI has to obtained through user input. The user inputs his SIP URI (minus the “SIP:” scheme id, as well as AD credentials (in most cases these are the same, a UPN such as tfl@gktrain.net).

For fun, here’s a PowerShell script to get and display the target domain from the AOR

# Get-DomainFromAor.ps1
#
gets the domain from the AOR and displays result
#
Thomas Lee - tfl@psp.co.uk

# Specfy an AOR
$AOR = "sip:tfl@gktrain.net"

# Get target domain
$domain = ($aor.split("@"))[1]

# Display results
"AOR : {0}" -f $aor
"Target Domain : {0}" -f $domain

Having discovered the target domain, MOC’s auto-discovery then synthesises a series of DNS queries, and sends these to the local DNS server – one at a time until a successful query result is obtained (or not). If a query is successful, then the information in that query is used to find the user’s OCS server. If no query is successful MOC can log the user in.

As an alternative to auto-discovery, of course, the user can enter the server details manually. In that case, MOC used the manually entered information and does not attempt auto-discovery. To simplify the user experience, and reduce support costs, you should implement DNS-based auto-discovery.



There are two types of synthetic DNS queries that are used by MOC: synthetic SRV record queries and synthetic A record queries. Synthetic SRV records search for an SRV resource record that in turn points to the A record. Together the SRV and associated A record specify the IP address and port number that MOC uses to connect to an OCS Server for the target domain. Synthetic A record queries look for an A record that has the IP address of an OCS Server. MOC uses this address, plus a specific per-query port number to attempt the connection to an OCS Server for the target domain.



The MOC auto-discovery mechanism attempts the SRV queries first, and the A record queries next in an attempt to find an OCS Server. For clients conneting inside the organisation, the discovery should take just one query (and response). For external clients, e.g. connecting from the internet via OCS Edge services, there will be more.



The specific order that queries are conduced are as described below.



Order of Synthetic DNS queries


As noted, Synthetic SRV queries are attempted first. If these are not successful, the synthetic A record queries are used. Here is the order:


(SRV Queries first)




  1. _SipInternalTLS._tcp.<target domain>


    If this query is successful, DNS returns one or more SRV resource each with an associated A record. MOC uses the first SRV record, and it’s associated A record. Both DNS round robin and SRV Record priority settings are be used to semi-randomise or to bias the order the SRV records are used. 
    MOC takes the host name and port contained in the returned SRV record and the IP address specified in the associated A record to attempt to negotiate a SIP over TLS (over TCP) connection with OCS.


  2. _SipInternal._tcp.<target domain>


    If this query is successful, DNS returns one or more SRV records and an associated A records MOC uses the host name and port contained in the the SRV record and the IP address specified in the associated A record.MOC uses the first SRV record, and it’s associated A record.Both DNS round robin and SRV Record priority settings are be used to semi-randomise or to bias the order the SRV records are used. MOC takes the host name and port contained in the returned SRV record and the IP address specified in the associated A record to attempt to negotiate a SIP over TCP (i.e. insecure) connection with OCS.


  3. _Sip._tls.<target domain>


    If this query is successful, then the steps shown for query 1 above are taken and a TLS connection is attempted.


  4. _sip._tcp.<target domain>


    If this query is successful, then the steps shown for query 2 above are taken and a TCP connection is attempted.


    (A Record Queries next)


  5. _sipinternal.<target domain>:443


    If this query is successful, then the MOC Client attempts a TLS connection to the IP Address specified in the returned A record, over port 443. 


  6. _sipinternal.<target domain>

    If this query is successful, then the MOC Client attempts a TCP connection to the IP Address specified in the returned A record. NB: The formal spec does not specify a port number, but it is believed the connection attempted is over port 5060. Cites pro/con  and corrections are most welcome.


  7. sip.<target domain>:443


    If this query is successful, then the MOC Client attempts a TLS connection as per query 5.


  8. sip.<target domain>

    If this query is successful, then the MOC Client attempts a TCP connection as noted in query 6 (with same note).


  9. sipexternal.<target domain>:443

    If this query is successful, then the MOC Client attempts a TLS connection as per query 5.




  10. sipexternal.<target domain>


    If this query is successful, then the MOC Client attempts a TCP connection as noted in query 6 (with same note).

    And just when your head explodes, there’s a bit more. Since DNS response times are not predictable, and DNS responses are not reliable, the auto discover mechanism does a bit more than just try these in order.



    As I noted, the client first tries to complete the SRV record queries. The client uses the queries in the order shown above to attempt to construct a list of candidate servers and once this list is complete, it begins attempting a connection. If queries 1 and 3 (TLS) above are completed and are successful before query 2 (TCP), then the client adds the  TLS entries from both queries and ignores the TCP entries.  If query 2 completes first, MOC waits till query 1 and 3 complete before moving on.



    One potential security risk is DNS Poisoning, for example by a hacker returning a ‘bad’ SRV record (ie pointing to a rogue server). The MOC client ignores responses whose domain/subdomain is different from the calculated domain. Thus if a query returned an record pointing to a server called ocs.fakedomain.com MOC would ignore it.



    After getting the results of the SRV queries, the client will move on to the A record queries. As a general rule, SRV records are used for internal clients, while A records are used for external clients. BUT: given this is DNS, you can use some, any or all of these various records as you choose (or indeed none of them and use manual configuration).



    A final note for larger enterprises. If you have a large enterprise, you may have multiple pools and therefore multiple SRV or A records are returned. In this case, MOC’s list of servers to try are dictated by the order the RR's are returned and the first record might be a valid OCS server, but the user is not homed on that server. OCS handles this via the director function and can re-direct the client to the users’s correct home server. The director function is separate and independent to the auto-discover mechanism



    Best Practices



    The best practices I can recommend are:




    • Keep it simple, and just use the minimum of DNS records. There’s not need to populate ALL these A records for MOC auto-discovery.


    • For internal clients, the only SRV record you need is  _SipInternalTLS._TCP.<target domain>. Set the port in the SRV record to 5061 and the host record to the FQDN of your OCS Server.


    • For external DNS, just use SipExternal.<target domain> and ensure that your edge servers and firewalls open up just port 443.


    • Where possible, avoid the use of SIP over TCP. If you are considering using SIP over TCP, consider the security implications very carefully.


    • Remember that other components of OCS (e.g. the DVT) may require different records to work properly (I’ll blog about this more, when I get a chance).



    Troubleshooting



    Troubleshooting OCS auto-discovery is for the most part simple – ensure you have the correct records are in DNS and that these are properly configured.



    Some things to look out for:




    • Assuming you follow best practice, can you resolve _sipinternaltls._tcp.<target domain>.


    • Is the sip target domain actually spelt correct in the AOR (eg tfl@gktwain.com vs tfl@gktrain.com)


    • In the SRV records, is the port number correct (5061 for TLS, 5060 for TCP).


    • In the SRV records, is the name of the host correctly shown (OCS-STB.Gktrain.NET vs OCS-STD.GKtrain.Net).


    • Does the SRV’s host name point to an A record that exists.


    • Make sure you have at least some records – preferably following recommended best practices!



    You can use the client’s event log to see failed DNS queries – this shows AOR problems when you see a lot of records missing in the event log. It can also mean that the SRV records are missing or incorrectly specified.



    If I get the time, I might try to write a PowerShell script to construct the synthetic queries, execute them and report on what’s found. Had enough yet? :-)



    Technorati Tags: ,,




Exchange/Outlook Autodiscover Feature

I was browsing the TechNet library today, and noticed an article on troubleshooting Error 0x8004010F, when occurs when Outlook 2007 tried to download the OAB from an Exchange 2007 server. The article is OK, if you understand what it’s saying, but like many articles can be confusing.

When you run Outlook on a domain joined computer, Outlook can make use of the domain information to access the active directory and obtain Service Connection Point information - i.e. details of where Exchange is, and this information in turn can help Outlook to locate your correct Exchange server (and download the OAB).

In some cases, e.g. when the machine is not a domain member, this process does not work. To cater for this situation, Microsoft has provided another way to obtain the relevant data making use of DNS.

But first some background. Windows services can use the Service Publication feature to advertise themselves using AD objects, in particular service connection points (SCPs).  A client application, e.g. Outlook 2007, can use the SCP information to bind to a service, in this case to Exchange 2007’s Client Access Server and then discover details about the Outlok user. This feature is known as Exchange 2007 Autodiscover.

As per the Autodiscover white paper, Exchange 2007 registers a SCP in AD for each server running the CAS role. These SCPs contain the serviceBindingInformation attribute (holding the FQDN of the CAS server in the form of: “https://cascookham1.gktrain.net/autodiscover/autodiscover.xml) and the keywords attribute (containing the AD sites to which this server is associated. i.e. the AD site the which this CAS server resides).

Outlook uses this information to access the autodiscover web service. Outlook first contacts the AD to retrieve all the relevant SCP objects. Outlook first tries to find a CAS server in its site and if this is not successful, it tries to find any CAS server in the forest. The white paper describes the creation of in-site and out-of-site lists and how these are used to locate the CAS Server.

Once Outlook then uses the SCP records to contact the autodiscover service on the CAS, based on the contents of the the serviceBindingInformation attribute noted above. When Outlook queries the autodisover service, the service queries the AD to obtain connection settings and URLs for all Exchange Services. The service then returns this information to Outlook in an XML document. Outlook then uses the information to locate the appropriate configuration information and connection settings for Exchange.

When running Outlook on a non-domain joined machines, this basic process doesn’t work, since the computer is not able to access the AD. In such cases, Exchange provides a second method to help Outlook to locate the autodiscover service and obtain the relevant autodiscover information (i.e. to obtain the autodiscover.xml file).

If the normal SCP method fails, then Outlook determines the name of the SMTP mail domain (it’s on the right side of the user’s e-mail address). If my SMTP mail address is tfl@gktrain.net, then the relevant domain is gktrain.net. Outlook then constructs two URLs based on this domain and tries each of them. These URLs are

  • https://<smtp domain name>/autodiscover/autodiscover.xml (in this case, https://gktrain.net/autodiscover/autodiscover.xml)
  • https://autodiscover.<smtp domain name>/autodiscover/autodiscover.xml (in this case https://autodiscover.gktrain.net/autodiscover/autodiscover.xml).

So if you are using Exchange and Outlook and seeing this error – then setup the appropriate DNS records in your corporate DNS to facilitate DNS based autodiscovery. The white paper also looks at issues around SSL certificates, connecting to the autodiscover service form the Internet and how to deploy and manage this service in both enterprise and hosted environments.

04 July 2008

Communications and Collaboration: How Voice Powers OCS 2007

Technorati Tags: ,,,

Found this nice article online today. Entitled Communications and Collaboration: How Voice Powers OCS 2007, the article takes a look at how calls are made and secured using OCS. OCS makes use of SIP as well as RTP and ICE to make the call, something the article makes very clear.

05 June 2008

Office Communications Server - To UDP, or not to UDP, that is the question…

The question “why doesn’t Microsoft support SIP over UDP” comes up a lot in the OCS training I run. It’s a hot topic at times, all the more so since the RFC requires (“must” vs “should”) UDP support. I’ve offered up the main reason – security, plus the nature of UDP vs TCP. It’s convinced some delegates, but sadly not all. To try to help answer this question, the OCS team have produced a great summary of this reasons in their post entitled To UDP, or not to UDP, that is the question…

Whilst the first and third reasons cited (security and  the fire/forget nature of UDP) was obvious, the issue of fixed UDP packet size had not occurred till I read their post. Looking today at some network traces of a client logon, there are indeed some large-ish XML files included with the SIP traffic. Use Snooper to take a look! And the level of support for SIP over TLS/TCP was surprisingly high.

Thanks for a great summary!

Technorati tags: , , ,