This is an article I first published a couple of years ago to check what schema version a customer was running when performing an Exchange upgrade.  There have since been official articles published by Microsoft, but I prefer to keep my own blog post for easy access.

This article outlines how to find the Exchange schema and version in of your Exchange schemas. There is also a list of the schema versions per build type.

To find the attributes listed below use Adsiedit.msc. When you launch asdiedit.msc there are 3 containers listed.

  • Domain: [Domain Controller FQDN]
  • Configuration: [Domain Controller FQDN]
  • Schema: [Domain Controller FQDN]

Read More →

This past Monday Ross Smith from Microsoft Exchange Team, posted the Exchange 2010 Mailbox Server Role Requirements Calculator during one of his sessions at the Exchange Connections conference in Las Vegas.  This tool is the equivalent of the Exchange 2007 Storage Calculator.  It’s actually a giant Excel spreadsheet.  It’s a useful tool to assist in sizing your Exchange servers and storage.  There are many assumptions made when using this calculator, so you always want to test, pilot, and deploy in phases to production.  I’ll be posting some of my Best Practices in another blog soon.

http://msexchangeteam.com/archive/2009/11/09/453117.aspx

Activating Standby Continuous Replication Targets

http://technet.microsoft.com/en-us/library/bb691321.aspx

 

http://technet.microsoft.com/en-us/library/bb676502.aspx

http://technet.microsoft.com/en-us/library/cc164368.aspx

http://msmvps.com/blogs/ehlo/archive/2008/01/08/1447442.aspx

Thursday, April 30, 2009 2:56 PM by Eric Norberg

 I have recently received a number of questions surrounding the generation of e-mail addresses in Exchange 2007. Particularly, whether or not custom email addresses can be generated via “legacy” replacement strings to meet specific organizational naming conventions.
This post will present a brief overview of the process as well as offer numerous examples which should assist you when tasked with creating your own custom proxy address templates in Exchange 2007.

Read More →

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)

 

 

 

  • _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.

  • _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.

  • _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.

  • _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)

  • _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. 

  • _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.

  • sip.<target domain>:443 

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

  • sip.<target domain> 

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

  • sipexternal.<target domain>:443 

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

  • sipexternal.<target domain>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? 🙂

     

(Borrowed from a post by Thomas Lee: http://tfl09.blogspot.com/)

The OCS 2007 Address Book service’s primary purpose is to provide updated GAL information to the OC 2007 client. It will also provide phone number normalization service for OC 2007 clients. The ABServer.exe is scheduled to query AD periodically for updates to user / group /information and provide this delta of updated information to the AddressBook share as .dabs files. After the initial installation and at 1:30 AM every day after that ABServer.exe will provide a full update to the AddressBook share with a lsabs file.
Read More →