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!

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.

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.

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: , , ,

15 May 2008

Getting the Tanjay Working

One of the cooler aspects of Microsoft's Office Communications Server is the Tanjay telephone device. Tanjay was the code name for what technically I should now call the Microsoft Office Communications Server 2007 Phone Edition phone. Tanjay is, however, so much less typing.

The Tanjay was one of three hardware device types that Microsoft developed for OCS. These, and more, are now sold by third parties. In addition to the Tanjay, there was the following code-name devices:

  • Catalina – this was a USB handset to provides a more familiar phone experience for Office Communicator users. The Catalina is effectively a fancy mike/speaker attached to your PC via USB. Polycom make one of these.
  • Anacapa – This is a blue tooth headset that can be used for receiving Office Communicator calls. This device is a USB dongle which speaks Bluetooth to a serrate headset (the pairing is done at the factory). To the host this is just a USSB speaker and mike - so no flakey BT drivers to load! Nortel make one as do Plantronics.

At present, there are two models of the Tanjay on the market: the LG Nortel 8540. The other is the Polycom CX700. In theory they are meant to be broadly equivalent and are priced similarly at around US$600.

I've got a pair of the LG Nortel devices and managed last week to finally get them working. The whole process is rather convoluted and very hard work, but do-able.

There are two main parts to getting the phone working are:

  • Basic connectivity - getting the phone out of the box and able to make/receive basic calls.
  • Configuring and configuring device updates - to get the most out of the Tanjay, you need to update the bios.

To some degree, you have to get basic connectivity working before you can get the device updates to work.

The steps required to get basic connectivity established are:

  • Configure DHCP
  • Configure DNS
  • Configure NTP
  • Configure DHCP
  • Configuring Certificates
  • Testing it

Configuring DHCP

The Tanjay device gets it's IP address information via DHCP. You need to setup your DHCP servers with sufficiently sized scopes that contain the following DHCP Options:

  • Option 3 - Router (IP Default gateway for the phone)
  • Option 6 - DNS Servers (one or more DNS servers)
  • Option 15 - DNS Domain Name (default domain name for the phone)
  • Option 44 - WINS/NBNS Servers (One or more WINS servers)
  • Option 45 - NBNS Node Type (set to 0x8).

In my case, my devices shipped with beta firmware (which worked but needed to be upgraded). The WINS server is used for the beta code and in particular to enable the phone to find the DC via NetBios (for DCs on remote networks). The RTM firmware now uses DNS for name resolution via option 6 where the phone is in the domain specified with option 15.

You also need to configure DHCP to support Option 119. This allows the device to have multiple domain names the device should the device can't for some reason, resolve a domain controller using the DNS servers specified via Option 6

Configure DNS

In operation, the Tanjay is just a Office Communicator client. It has to register to an OCS server and use that Server to negotiate phone calls.

The Tanjay uses a combination of SRV and A records to find the OCS resources. You may need to add 4 different groups of records (in addition to the DNS RRs implemented by AD):

  • NTP - you need a SRV record that points to the FQDN of the time service (see later for setting up NTP). This has the format:

_ntp Port:123 <FQDN of NTP Server>

  • Internal SRV records - you need potentially two SRV records to your internal DNS Server, These enable the Tanjay to discover internal OCS resources. The first (_SIP._TLS.<sipdomain>) is for TLS connections and the second (_SIP._TCP.<sipdomain>) for TCP connections. For both records, the host has to be either you SE Server FQDN, your EE Single Server FQDN, or a FQDN Pointing to the hardware load balance. The ports are the normal posts (5061 for TLS, 5060 for TCP). These in turn resolve to the A record with the relevant IP address (or VIP address for the HLB).
  • External SRV records - you need potentially two SRV records to your external DNS Server, These enable the Tanjay to discover external OCS resources
  • A record(s) for your SIP Domain. In your internal DNS, you need an A record for SIPInternal.<sipdomain> which points to your OCS FE server (or HLB).In your external DNS, you need an A record for SIP.<sipdomain> that points to the Access Edge server

Configure NTP

The Tanjay uses NTP to get updated time - synchronised time is a requirement for Kerberos authentication. The device uses the UDP SRV record noted earlier to locate the relevant NTP server. Your NTP server can be any NTP server, but my preference is for it to be a DC.

As I understand it, the Tanjay can use the Internet and can access external time servers (e.g. time.windows.com). Some organisations block NTP externally or have Tanjay devices that are operating in networks that are not attached - and for these situations, we need to configure a local NTP server.

To configure NTP, look at KB article 816042 - How to configure an authoritative time server in Windows Server 2003.

Configure Certificates

This Tanjay uses X.509 digital certificates to create the TLS tunnel for connection OCS. To get your Tanjay to log in securely, it's necessary to get your Root CA cert into the trusted root store on the phone. This proved to be a very major pain.

In my case, I first loaded the certificate onto a temporary share on the DC. Then I logged into the Tanjay using a domain account. To to that, you need to exit from the phone app (aka Domo), and use native WinCE features. You have to set the owner User ID, Password and domain. This may sound simple, but when you get the relevant dialog on the screen, the soft keyboard pops up neatly obscuring the screen (and no way to move the darned soft kb). But once you get the credentials entered, you can use the network to download this cert to add it to the device root CA. For testing, you might create a short user name with a very short password!

If you are using the Tanjay externally, you will typically need to use a public cert for your Access Edge. Note that the set of public Root CAs trusted by default by the Tanjay is more limited than the full Windows client - so choose your cert provider carefully. And check that you don't need to export your CA's root cert to the device as well as the internal CA cert!

You also need to configure your domain so that clients autoenroll for the Root CA Certs, which makes some of the pain go away.

Testing it

Once you have all the above items configured, you can get your device to make/receive calls, advertise and view presence, etc. You need to reboot the device (I just turned the power off and on). As the phone comes up, you can see it getting an IP address.

After may trial and errors, it took me around 3 hours to get this far. Due to time constraints, I did not have time (that day) to get the update server working, but I'll report on that in Part 2 of this blog post. And in closing, I would like to personally thank Dennis Herzig of Global Knowledge for providing the solid and feature rich Virtual Image environment that has made this all possible!

Technorati tags: , , , ,