Monthly Archives: June 2009
We have done many deployments that have been LCS 2005 to OCS 2007 R2 migrations, however recently we encountered our first experience where migrating the global settings from the System Container to the Configuration Container in Active Directory was requested by the customer.
This process is outlined in documentation provided by Microsoft that can be found here: http://www.microsoft.com/downloads/details.aspx?FamilyID=23236784-508e-44c9-809d-30ff245928d8&displaylang=en
The important thing to note here is that the documentation is clearly outlined for OCS 2007 R1 to R2 migration scenarios, NOT LCS 2005 Sp1 to OCS 2007 R2 Migration Scenarios. The documentation states this works for LCS as well as OCS however, we ran into a bunch of flaws in the documentation that I will outline below with workarounds.
First off, LCS was never meant to work with the configuration container, Microsoft released an update here: http://support.microsoft.com/kb/911996 that supposedly would fix this. Basically if you had not installed that KB Update and tried to use LCSCmd to prep the forest with the /global:configuration switch it would error out with Invalid Parameters. Once you install this patch, the LCSCmd will take the /global:configuration switch and report a success. The interesting part here is that any version of LCS 2005 Sp1 Forest or Domain prep will not perform the correct functions on the Global Settings if they are stored in the configuration container and the system container at the same time. The hard thing about this is that the documentation states to wait to delete the system container information until testing all services, unfortunately this is impossible.
Here are the various issues I ran into while performing this migration. First off, the scripts do their job just as they should, the script would successfully migrate the Global Settings containers to the Configuration Container. We did however start running into some minor issues when we went to update the user DN References. We noticed the user DN references script was not making any changes and kept saying it was not complete.
We decided to check the msRTCSIP-PrimaryHomeServer setting to see if these changes had indeed been made, we viewed users in different OUs and confirmed they were pointing to the configuration data for their home server.
From here we started to panic so we decided to test if we could start the LCS Service. The LCS Service would fail to start with the error messages shown below:
When using lcserror.exe to lookup the error code provided in the last error this was the response:
In the LCS Management Console there were two pools showing up, both with the same name. One pool would have no servers and users, and the other would have all of the servers and users. This was a good way for us to confirm that all users and servers were pointing to the Configuration Container for their information. The above error states it cannot find the AD objects it needs, which still didn’t seem to make sense because it was pointing to the configuration container. When checking the objects through ADSI Edit I noticed that the global settings containers were in the correct places, however none of the proper permissions had been applied to them, this usually happens during Domain Prep, which as I had mentioned above will not work with the global settings being in the System and Configuration Container at the same time. We manually added the RTCDomain groups to the containers with the proper permissions however the services still would not start.
Microsoft was able to confirm that the LCS Services would not start with the information in the System Container as well as the Configuration Container. After using the migration script to delete the System Container information the service still failed to start. I ran a domain prep check on the domain and was able to see the Microsoft container was not showing as ready. Once the domain prep was run again, all permissions were correctly added to the objects in the Configuration Container and the LCS Services would start and everything was functioning again.
To summarize key things to note about the process that differs from the documentation:
- You must delete the information from the system container before running domain prep or else Domain Prep will not be able to add the permission correctly and the LCS Services will not start.
- When updating the user DN References it may not always show as completed, however you can verify by checking the msRTCSIP-PrimaryHomeServer setting through ADSI Edit.
Hopefully Microsoft can get this documentation updated soon, or atleast an announcement about this in a public blog, I have to imagine this is causing a lot of havoc on the LCS to OCS Migrations.
In my previous post I outlined how to record Custom UM Auto Attendant Prompts in the correct format for Exchange 2007 UM. This post will outline how to import these and apply them to UM Auto Attendants, Part two will cover some From the Field Experiences the WinXnet team has developed to outline how we suggest utilizing the auto attendants in customer and internal deployments.
First step once you have these recorded and have the files on your Exchange UM server is to import them into the Dial Plan directory so they can be assigned to the auto attendants. The .WAV files themselves can be stored on any drive local to the UM server, however there is a power shell command that must be entered to publish the file to the UM Prompt Publishing Point. The UM Prompt publishing point is a shared folder that is created on the first UM server installed in the exchange organization; any additional UM servers in the environment check periodically and update their Prompt Cache based on the files in this folder.
See below for the power shell command and syntax that goes along with this:
Copy-UMCustomPrompt –Path -UMDialPlan
The string entered to generate the logs below in my environment was: Copy-UMCustomPrompt –Path E:\winxgreetingnew.wav –UMDialPlan WXUM
This command will simply return a fresh power shell line and the cache update process will be started. To confirm the files have been updated in the UM Cache you want to look for these Informational Messages in the Event Viewer.
This first message confirms that the custom prompt files were updated:
This second message confirms that the cache update process has been completed by the server, this happens every 5 minutes on the UM Server by default:
Now that the files are in the cache for UM, we can assign to an auto attendant. To do this select your Auto Attendant properties and choose the Greetings tab, see below:
After a few minutes of replication for changes this greeting should now take effect when you call the Auto Attendant. You will notice the spacer settings of this auto attendant which I am going to follow up on from the WinXnet UC team experiences around using the UM Auto Attendants.
We recently did a lighthouse deployment with a very old PBX, the Avaya Definity G3r. There were a couple minor complications to this configuration however we were able to get through it with no issues and have full call flow between the two systems. I wanted to share the configurations we implemented in case anyone else runs into this unique PBX scenario.
Again we were utilizing a dialogic DMG2120 gateway for this implementation, if you notice on the Dialogic interoperability site you will not see any guides for the Definity G3 and OCS. http://www.dialogic.com/microsoftuc/pbx_integration.htm
We noticed in the exchange UM portion they had information for CAS signaling, however we could not get the CAS signaling to work properly so we decided to go with a T1 ISDN connection. The PBX would not support the QSIG standard so I reached out to our local support channel for some guides with the NI2 ISDN protocol. Dialogic does not currently have any official documentation around this setup, however they were able to provide some basic screens for me to hand off to the Avaya admin, and you can see these configurations below: (Note: These configuration screenshots were provided by Dialogic, I did not produce these)
Those screens above will get your Avaya side ready to handle the NI2 signaling from the dialogic gateway. The Dialogic side of this configuration is very basic and can be found below:
This customer also was one of the customers requiring #9 to get out to the PSTN which you can find a fix to in my previous post here.
A common confusion I am seeing from talking with customers and other engineers in the field is getting custom Greetings and Menu Prompts created for the Exchange 2007 Auto Attendants. The program of choice for me when creating these files is Goldwave, you can download the program with a free trial here. This trial version will get you all that you need for a certain time period to record all of your exchange recordings, however I would suggest supporting them and buying the product!
Below are screenshots and a basic walkthrough of creating a recording you can import into exchange 2007 for an auto attendant prompt.
Create a new file in Goldwave by clicking New or going to File->New. Choose the settings for a Mono recording and 8000Hz as the sampling rate and click OK.
To verify the input audio device is correctly set to your headset microphone click the button Highlighted in the above picture.
Choose the “record” device from the drop down menu and hit OK.
Hit the red record button in the middle and start recording the greeting. Hit stop when finished.
Select the unused space, make sure it is highlighted in blue, and hit the Delete key to remove all unused space so you are left with just recorded audio in the file.
Choose File->Save As. Save the file with the Attributes field as shown above: PCM signed 16 bit, mono. Make sure the file type is Wave (*.wav)
You now have a file that Exchange will work with as a Greeting or Main Menu Prompt
I will do a follow up post with importing these wav files for use and some tips and tricks from the WinXnet team on working with the auto attendants and their greetings.
Typically organizations require a 9 or some other combination of digits to get out to the PSTN for outbound calling. At two recent deployments I ran into a scenario where the feature access code for PSTN dialing was #9. These customers had internal extensions in the 9000 range so it was not possible to use just a 9 for a feature access code. There are a couple tricky parts to this, as well as a dialogic bug which has since been fixed.
The first tricky part is that OCS does not work with a # or a * in normalized phone numbers. The simple workaround for this was to have users enter a #9 before outbound calls, but normalize it to +9 like OCS is used to dealing with. From there this matches outbound routes and goes to the Dialogic gateway to pass on to the PBX for outbound calling. At the gateway we make a routing statement in outbound calls to replace the + sign with a # so the number now looks correct for the PBX. This configuration can be seen below:
After running many tests all of our outbound calls were reaching the internal switch boards, or failing due to an unknown user. On the outbound call logs from the dialogic we would see the full number being sent (#912075551234). While talking to the PBX Administrators they claimed not to see a # sign and were only getting 4 digits, this was not matching any users so it was routing to the switchboard or failing. After some minor arguing back and forth about who had their settings set correctly to send the information I realized there must be an issue with the dialogic. I reached out to my local support channel that was able to confirm the bug, and the development team has come up with a fix.
Below is a link to experimental modified firmware for the DMG2120 series gateway when using a T1 ISDN connection. You should only apply this if you are having the need to send a # or * character in your call invites. This will be built in to the next public release, but I wanted to make sure people had some awareness of this if currently having this issue with deployments.
Typically the two workloads of Exchange Unified Messaging and Office Communications Server with Enterprise Voice were deployed separately. Most Companies adopted Exchange UM before OCS, or Companies were deploying OCS in a pilot scenario and integrating with their existing PBX messaging system.
As these products become more mature we are seeing complete deployments of both workloads. At a recent deployment in a Boston based law firm users are being enabled for OCS enterprise voice as well as Exchange Unified Messaging and abandoning their legacy avaya phone. All of the laywers at this company have a telephone number and a fax number, a common difficulty is that the OCS Mediation server does not support the fax protocol. Therefore when deploying OCS as the main endpoint for a user, call flow comes through the mediation server, any faxes sent over this trunk would fail because the mediation server cannot handle the T.38 protocol.
I read a blog post from Mino (The UC Guy) linked here. Mino explained this scenario with a solution that included a secondary dial plan being assigned to users. The key part to this solution was also a second trunk from the pbx that is routed directly to the Unified Messaging Server instead of through the Mediation server.
At the customer in question we had already setup a separate trunk to the UM Server so they could provide all users with Exchange UM Functionality but slowly Migrate users to OCS for voice. We were already routing the faxes directly to the UM server by modifying the coverage path of their fax extension to our UM Pilot Identifier. You can see on the log from the DMG2120 below that the call was routing to the Exchange UM server without any issues, however in the exchange logs it could not find a user.
For the same reason that we had two seperate trunks for UM only users and OCS-UM users we had a secondary dial plan for TelExtn.
I am not sure if this is a commonly known thing however you must click the down arrow to add a EUM address rather than an SMTP address:
This is the same thing as executing this commandshell command provided in Jen’s blog post:
Set-Mailbox -id Randy Wintle -SecondaryAddress 61 -SecondaryDialPlan UmDialPlan
Once the second extension was added to the user (separate screenshots from the deployment and my internal testing), the fax would route correctly to the user and appear in the user’s mailbox.
Luckily for us we already had the ground work built without realizing the faxes would not go through.Now the next step is to get rid of the Avaya PBX completely and have all users utilizing the full Microsoft UC Platform J
A recent deployment integrating with an Avaya S8700 PBX utilizing a DMG2120 gateway to OCS ran into some issues when routing users extensions over to OCS for the piloting phase.
Because of the strain of creating individual routes for each pilot user when their extensions were not in a consecutive block, we have had many scenarios where the customer will forward their legaxy Avaya phone to either a new extension or a pilot identifier on the pbx. In a previous post I outlined the setup where users are assigned new extensions in OCS and they forward their deskphones to that extension. These extensions are a consecutive block so the Avaya routing is simple, all of the numbers matching that pattern route to the pilot identifier for the T1 trunk to the dialogic gateway. From there we would have a CalledNumber on the Dialogic of the new extension, which would route to OCS and do a lookup to ring the Communicator End Point.
The new scenario here was not having a new block of DIDs to forward to, instead attempting to forward to the Pilot Identifier of the T1 trunk on the avaya. Unfortunately I do not have any screenshots from the dialogic logs as this was done in realtime, however I will explain the steps as much as possible below.
The good news is the when forwarding the station to the pilot identifier we would see information hitting the DMG Gateway. This is where a screenshot from the call log would be handy, but basically we were receiving a Called Number of the Pilot Identifier and a Redirect Number of the users Avaya extension. The problem here is OCS cares about the called number, so a user lookup would fail. The DMG Gateways are great with modifying all parts of a call for the invite to go to OCS, we replaced the Called Number with the Redirect Number, giving OCS a number to perform a lookup and reach the user.
Unfortunately we ran into another issue here, this still was failing so running traces through the OCS Logger and Snooper we could see the numbers coming through but failing with Bad Voip Request errors, the same was showing on the dialogic in the call logs. Turns out, OCS does not handle a Redirect number being in the SIP Invite too well in this scenario. The end fix was to remove the Redirect Number all together, so the only information being sent to OCS was a Calling Number and a Called Number. The configuration information can be seen below:
Kudos really goes out to the dialogic team for having such a friendly interface and providing great help in the UI for their routing statements.