Tuesday, February 17, 2009

ExchUCUtil.ps1

Connecting Office Communications Server 2007 to Exchange Unified Messaging gives a lot of people some trouble. There are plenty of Blog entries out there about the connection Script ExchUCUtil.ps1 but none that seem to explain what this script is doing. Recently at a customer site I ran into a problem where the ExchUCUtil.ps1 and get-Ucpool.ps1 did not work correctly. Hopefully this information will help give an understanding so trouble shooting will be easier.

The script performs the following tasks:
Creates a UM IP gateway for each Communications Server 2007 Enterprise Pool.

  • Creates a hunt group for each gateway. (The pilot identifier of each hunt group specifies the UM dial plan used by the Enterprise Pool that is associated with the gateway.)
  • Grants Communications Server permission to read Exchange UM objects in Active Directory.

Location of the ExchUCUtil.ps1 and Get-Ucpool.ps1

C:\Program Files\Microsoft\Exchange Server\Scripts

The ExchUCUtil Script Creates Gateways for Each Communications Server 2007 Enterprise Pool that it finds in AD. It uses the Get-Ucpools.ps1 Script to find those pools.

In the FindUCObject function there is the following code

  1. $globalCatalog = $entry.psbase.Properties["rootDomainNamingContext"].Value;
  2. $entry.psbase.Path = "GC://" + $globalCatalog
  3. write-host Using Global Catalog: $entry.psbase.Path
  4. Write-host

    Line number 2 is where the script tries to set up and define your root Global Catalog Server
    If your Script is having problems you can comment out line number 2 by using the Hash sign (#)
    Once you have commented out that line you can directly specify your GC like the example below.

  5. $globalCatalog = $entry.psbase.Properties["rootDomainNamingContext"].Value;
  6. #$entry.psbase.Path = "GC://" + $globalCatalog
  7. $entry.psbase.Path = "GC://MYGCin.Domain.com"
  8. write-host Using Global Catalog: $entry.psbase.Path
  9. Write-host

    This will direct the script exactly at the main GC of your forest.

    Once the Script has found the correct GC it starts the hunt for the UC Pools that are in the environment by looking for objectCategory=msRTCSIP-Pools. This will return the pool names back to the Get-UCPools Script and it will put the pools in a hash table using the DnsHostName as the key.

    After the collection happens in the Get-UCpools.ps1 script the EchUCUtil.ps1 script starts to parse through the data stored in memory by the Get-UCpools Script. It will identify all the pools in the environment and will have them by fully Qualified Domain Name. The example is OCSPool1.Domain.com. The ExchUCUtil script will create new gateways and Hunt groups per OCS Pool. It will take the name of the pool and set it as the gateway name and apply the FQDN of the pool to the address field of the gateway. The Exchange Power Shell command to create a new IP gateway is run a default hunt group is automatically created. This hunt group will be removed by the script and it will create one with the name of the dial plan as the pilot identifier and the name of the hunt group.

    After the creation of the Dial plans Gateway and hunt group the script sets the following permission to the Exchange Organization container, UM DialPlan and AutoAttendant Containers

    Permissions for group Domain.com\RTCUniversalServerAdmins


ObjectName

AccessRights

----------

------------

<Exchange Container Name>

ListChildren

UM DialPlan Container

ListChildren, ReadProperty

UM AutoAttendant Container

ListChildren, ReadProperty



Permissions for group Domain.com\RTCComponentUniversalServices


ObjectName

AccessRights

----------

------------

<Exchange Container Name>

ListChildren

UM DialPlan Container

ListChildren, ReadProperty

UM AutoAttendant Container

ListChildren, ReadProperty


If the script won't run at all you might have a larger issue. However it is possible to create the Gateway and Hunt Group by hand through the Exchange Management interface. Once they have been created a quick dive into ADSI edit setting the appropriate permission on the containers will leave the environment in the same state as if the Script had run from the Power Shell.


~Cheers!~

Microsoft Exchange Unified Messaging Architecture Considerations

The question that comes up more often than not with customers is how if possible can I make a remote site survivable for voice mail? There are some things that need to be considered before a decision like this is made. What does survivable mean in terms of the budget, resources and administration? Before we go down that road we need to talk about the functionality differences the user experience.

There are 3 major architecture considerations for unified messaging with OCS or a Gateway. Centralized,
Distributed UM Server Deployment, Distributed UM and Mailbox Deployment and each have unique affects on the user's experience. The problem with the last two options is the introduction of MAPI across a WAN. The exchange servers talk to each other using MAIP for certain requests. The Unified Messaging Server uses MAPI to get mailbox information and greeting information out of the user's mailbox.

When the Unified Messaging server uses MAIP protocol to retrieve user content the caller experience becomes degraded. If the round trip time from the Unified Messaging server to the Mailbox server is greater than or equal to 100 milliseconds the user's personal greeting will never be played. This is because the Unified Messaging server times out when trying to generate a temporary copy of the greeting stored file in the user's mailbox. Once the Unified Messaging server times out it attempts to play a copy of the users recorded name stored in the local sites DC. If that times out the Unified Messaging server will attempt to speak the user's name.

Centralized Architecture

The centralized architecture eliminates the possibility of having a bad users experience because of the latency on the WAN with MAPI. This solution does not support remote site survivability. If the WAN goes down the user will either hear fast bust tone from the OCS applications or dead air from the gateway. This solution relies on the WAN being up and the usage of SIP, RTP/SIP between the remote site and the Unified Messaging server in the data center. The centralized model eliminates the need for Unified Messaging servers and Mailbox servers in the remote sites. This also creates a centralized location for administration for both servers and application.

With the centralized deployment all users will get their personal greeting and Out of Office messages played to the callers. The further in milliseconds a user is away from the unified messaging server, the longer it takes for the ringing to stop and the auto attendant or subscriber access to answer. Once the subscriber access or auto attendant answers everything is local and the menu response times are very fast.

Distributed UM Server Deployment

The distributed Unified Messaging server Deployment at first glance looks good to most customers. The problem with this type of configurations is the introductions of MAPI across the WAN. In this configuration the site becomes survivable in the fact that all calls will be answered in some form by the server. However if the distance from the Unified Messaging server is greater than or equal to 100 Milliseconds the user's personal greeting will never be played. Also in this Configuration subscriber access and auto attendant directory transfer becomes increasingly slow. As the network latency increases so does the delay to log into a local subscriber access number. This is evident by the auditable hour glass sound Unified Messaging plays during the authentication process. To put this into perspective a users trying to long into outlook voice access across a T1 at 100 Millisecond delay, no jitter or packet loss, will have a 9.5 – 10 second wait until they hear their first voice mail.

This option is a common misconception for customers because architecturally it makes sense, however functionally it is worst out of the three. No network is perfect especially across the WAN and if personal greetings for users are a business requirement then this option is not for you.

Distributed UM and Mailbox Deployment

This option requires that all the Microsoft Exchange server roles are deployed in each location. This option is polar opposite from the centralized model which many customers are moving towards. The distributed architecture becomes a consideration if the business requirement of remote site survivability and low delay are mandatory. With this configuration there is still the possibility of a MAIP across the WAN scenario. If a caller contacts a local auto attendant and performs a directory-look-up to a user that is in another site, the system will attempt to play the personal greeting using the MAPI protocol across the WAN. This will time out and the personal greeting will never be played. Out of the three options this is the most expensive and administratively intense. There can be large mailbox storage, CAS, HUB and Mailbox redundancy requirements. Additionally to the servers an internet presence for the remote locations may be required to allow users to access their mailboxes through Outlook Web Access. This last option tends to be the best fit for Global regional data centers. This scenario would still employ the remote sites to SIP across the WAN for voice mail however users look up could allow MAPI across the WAN for voice mail transfer