Category Archives: Exchange 2007

Powershell Script to create new user, enable for Exchange, UM and Lync Server

I created this powershell for our internal onboarding process, figured I would share it with the masses.

I think there are a couple good takeways from this script, it remotes into Exchange 2010 and Lync Server 2010 Powershell sessions, so nothing except Powershell 2.0 is required on the client side, which is standard with Windows 7. It also shows how you can simultaneously use Exchange and Lync powershell commands in the same script to get things done.

A couple of disclaimers:

I am in no way advanced at powershell scripting, so nothing fancy here.

This was developed specifically for my internal needs, you will probably have to add/remove variables and requirements.


Script is above, any freedback is appreciated, if you improve on this at all, I would love to see it as well.


Reference: Setting Event Log Levels for Exchange UM

Exchange 2007 and Exchange 2010 allow you to configure different event logging levels for all Exchange services.

I commonly have to enable more detailed Exchange UM logging on UM servers to troubleshoot call flow issues, so here is a quick reference of how to do this.

First off, here is the technet reference to doing this for all services:

In Exchange 2007, you must do this through Powershell, Exchange 2010 however is available right in the Exchange MMC.

For Exchange 2007:

Start by opening your Exchange Management Shell

The following powershell commands are required for the Exchange UM services

set-eventloglevel -identity “MSExchange Unified Messaging\UMWorkerProcess” -level Expert
set-eventloglevel -identity “MSExchange Unified Messaging\UMCore” -level Expert
set-eventloglevel -identity “MSExchange Unified Messaging\UMManagement” -level Expert
set-eventloglevel -identity “MSExchange Unified Messaging\UMService” -level Expert
set-eventloglevel -identity “MSExchange Unified Messaging\UMClientAccess” -level Expert
set-eventloglevel -identity “MSExchange Unified Messaging\UMCallData” -level Expert

In Exchange 2010 the same powershell commands will work, however, if you are more comfortable with the UI, you can do it directly in the Exchange MMC.
First open the Exchange Management Console
Expand your On-Premise Organization and select Server Configuration

Select your UM server from the list of available servers, and you will notice on the right hand side, under Actions for that server you will have Manage Diagnostic Logging Properties

Select Manage Diagnostic Logging Properties and you will be prompted with a full list of services on your Exchange server to manage. Expand MSExchange Unified Messaging, for each service you wish to raise the level, select that service, and then select the option for whatever level you wish to enable. Expert is typically a good level to have if dealing with UM.
Once you have configured all of your service levels, choose configure. This will basically execute the Powershell commands listed above and confirm Completion.

Quick Tip: Exchange UM Powershell to list users in a specific dial plan

This is a basic one liner I needed to use today, but I didn’t find it documented that well anywhere.

Situation: Multiple exchange UM dial plans in a company, need to identify users associated with a certain dial plan for whatever reason. In this case it was to migrate them off that dial plan.

Going through the UI to do this would be way too time consuming, of course powershell comes to the rescue.

Using the Get-UMMailbox cmdlet with a basic filter we can identify a group of users with many different attributes in common, in this case we are concerned with UMDialPlan.

Command looks like this:

Get-UMMailbox | where {$_UMDialPlan –eq ‘DialPlanName’}

This will return a list of users in the dial plan you specify. You could of course add more filters in to narrow down the scope.

Alternative to RCC With Cisco and OCS 2007 R2

Often I run into customers that want Remote Call Control with their current phone system as an integration architecture with OCS 2007 R2. Personally I see the benefit to remote call control in LCS, and OCS 2007 R1, but not with the R2 release, and especially with Wave 14 so close. Many times I have had to explain the different scenarios, and why I think a different architecture is a better way to approach this. Today I had to develop this information for a Cisco Call Manager implementation, and wanted to have a reference point, as well as share my thoughts on the subject.

To give a brief background, the customer wanted RCC with Cisco, they currently have an OCS infrastructure in place, and wanted to add the RCC functionality to that environment. In order to do this, they would need to upgrade to Call Manager 7, which is the very first reason to not go any further with the RCC architecture in my opinion. If you are investing in the Microsoft Unified Communications technology stack, there is no reason to dump more money into another UC product along side it.

As a summary, here is a description of what RCC is… Credit goes to this blog post

This is a description from the R1 release of OCS 2007 but still holds true today.

Remote Call Control (RCC)


Also this voice scenario was already available in OCS 2007 predecessor Live Communications Server 2005 SP1. The users OC client does not act as a soft phone, does not need an audio or audio/video device connected to the PC and the user is not able to make or receive phone calls by using her/his PC. This is not a VoIP scenario!

User experience

In this scenario, an OCS 2007 user has a PBX or IP PBX phone with an extension (e.g. 1212) standing on her/his desk. In addition to that, Office Communicator (OC) 2007 is installed on the user’s PC.

In the office

On an incoming call the user’s PBX phone rings as well as that she/he receives an incoming call notification (pop-up window) on the bottom right of her/his PC screen, showing the Calling Party Number (Caller ID, phone number of the person who called) and also the caller’s name (if OC could resolve the phone number to a name by matching the phone number against Active Directory or Outlook contacts). The user is able to accept the call by picking up the receiver of the PBX/IP PBX phone or by clicking on the pop-up window for the incoming call on her/his PC. In both cases, media (voice stream) will stay on the PBX/IP PBX and there will be no VoIP connection to OC! The user does not need an audio device for telephony connected to her/his PC.

At home/on the internet

If the user receives an incoming call to her/his office number while being connected to the company’s IT environment over the internet (e.g. at home), the users PBX/IP PBX phone will ring in the office (what she/he most likely will not be able to hear J) as well as that she/he can see the pop-up window generated by OC on her/his PC. Accepting the call by clicking on the pop-up window will result in this scenario that the phone in the office will activate the speaker phone, but the user is not able to use her/his PC to talk to the caller. No VoIP connection through the internet is established! (However, the user can redirect an incoming call to her/his mobile phone and can pick up the call this way while working remotely.)

How it works in a nutshell

A CSTA Gateway (GW) needs to be installed between OCS 2007 and the PBX/IP PBX. Some PBX/IP PBX systems come with a CSTA interface natively so there is no need for an additional GW. Between OCS and the PBX/IP PBX call control commands will be sent, packed into a SIP INFO message that uses a long-lasting SIP dialog between OCS and the CSTA GW. The CSTA GW converts these call control messages into a format that the PBX/IP PBX understands. A CSTA GW is not a media GW so voice cannot be converted by a CSTA GW from a TDM (Time Division Multiplexing) or PSTN protocol to VoIP! OC can only control the functions of the PBX/IP PBX phone.


With a Cisco integration, we would actually be able to do direct sip as long as the following software requirements are met on the Cisco side:

  • Cisco Unified Communications Manager Release 7.0(2)
  • Cisco Unified Presence Release 7.0(3) with E.164 patch for RCC

One of the key features of the Microsoft OCS Platform is the ability to have not only integrated IM and Voice calling, but also conferencing, all within the same application, and all available through a single click. Any communication can be escalated to a conference by inviting PSTN or VOIP participants at any time. When you introduce the remote call control scenario this is no longer available. A Key thing to point out is that a user in this scenario cannot make or receive calls using communicator, they still must use the Cisco phone in all scenarios, which virtually eliminates the remote worker benefits of OCS.  Below is the list of other limitations taken from the Cisco Documentation on this configuration:

Features Not Supported

· Microsoft OC logon from two locations

· Call Forwarding

· Location Based

· Phone Settings

· Conferencing through remote call control


· Conferencing: OCS 2007 R2 does not support call conferencing through remote call control. Conferencing is available in IP Phone

only or OC only call scenarios.

· Call forward setting on IP phone: Call forward setting made on the Cisco IP phone (desktop), using its soft key button or the Cisco

UCM phone configuration page, is not reflected by the Microsoft OC GUI. As of Microsoft OCS 2007 release, this feature is not

supported. The Microsoft OC can override any call forward setting manually configured on the IP Phone and vice versa.

· Call Forward Setting from OC: Call forward setting from the OC through remote call control (RCC) fails on the IP Phone when the IP

Phone is initially configured with an E.164 DN. If the IP Phone is reconfigured to a non-E.164 DN then back to the E.164 DN, the

call forward setting from OC through RCC will work. This is a known issue on Cisco UCM 7.0(2) and has been documented in

CDETS CSCsy62620 to be fixed in a future release.

· Do Not Disturb (DND): DND is an unsupported feature with respect to CUP integration. Thus, any OC client with DND feature

enabled, will still have any received calls routed to its controlled IP Phone.

· Multiple Point of Presence (MPOP): As of the CUP release 6.0(1), the MPOP feature where a Microsoft OC user is logged in from

more than one location is not supported by CUP. Support for this feature affects other interoperability features between the Cisco

CUP and the Microsoft OCS. The affected features include basic placement and teardown of calls and locations-based call forwarding.

These features are inherent to MPOP and without support for this feature, the user experiences loss of device and call control when

logged in multiple locations.

· Transport Layer Security (TLS) connection between CUP and OCS: this feature was not tested in this release.

As you can see, you quickly start to lose a lot of the functionality of OCS. I will stress that the above is strictly related to Cisco, and may not be completely accurate for other RCC Scenarios.

The other option, and most optimal solution in my opinion can be most closely referred to as a standard Enterprise Voice Scenario. Really, it is the cheap way of doing remote call control.

Last year I had multiple voice deployments which had to provide interop between OCS and the existing PBX, mostly Avaya and Cisco systems. A key requirement of all of these deployments was the ability to pilot OCS functionality but also have access to their old phone for use. The architecture we used to provide this can be seen below. We had to make a connection between the OCS environment and the PBX, whether it was a Sip trunk to cisco, or a PRI connection via media gateway to the other systems. From there we have two options for routing incoming/outbound calls for OCS enabled users.

The first scenario is where the PBX controls the call routing. All PRIs, or SIP trunks come directly into the PBX, from there you have routing rules to route certain numbers over a trunk to OCS. This can be accomplished by setting routing rules at the PBX level, or simply forwarding your PBX Desk phone to your OCS extension, which will route it over to the OCS Trunk. It is important to note that in both scenarios you are configured for different extension on the PBX and OCS. Where your “real” extension goes depends on how you wish to route/forward calls. Regardless, any DID numbers, or existing extensions are still usable, it’s just a matter of getting the call there. In this scenario for example, you may have “fake extension” in OCS, and when your existing extension is rung, your cisco phone forwards the call to your OCS extension, in the PBX this new block of OCS extensions is configured explicitly to route over that new trunk, this is the simplest way to make this connection happen with the least amount of changes on the existing PBX environment.

The other scenario lets OCS control the call routing. In this scenario all PSTN calls destined for OCS Enabled users go directly to OCS. This can be more difficult to implement at first, but once it is in place, it provides a very smooth transition. This can be accomplished from a direct SIP trunking connection to an OCS mediation server, or a PRI/POTS connection from a provider, into a media gateway, which then sends the calls on to the OCS mediation server. It is possible to move all incoming PRI connections to a media gateway, which would then control all calls. From there that media gateway can send to the PBX or OCS. In the Cisco world, this could actually be a 2800 or 3800 series ISR. To some people this is a bit scary to hear at first, but really, your current PRI lines come into some sort of gateway device as it is, this would provide the same functionality. The gateways used are by companies like Dialogic and NET with great experience doing this for years for traditional PBX systems, so it is more than reliable. From here, there is also a trunk setup to the PBX to route extension dialing, as well as for simultaneously ringing the legacy PBX phone.  In both scenarios the voicemail can be sent to exchange unified messaging or back to the PBX voicemail system. When OCS has no answer, it can make this choice. The PBX will be smart enough when the call comes back and is tagged with no answer, to send it directly to voicemail instead of creating an endless ringing loop.

In scenario two, if the media gateway takes all PSTN calls in, it will have some basic routes on it. Routes that control sending OCS enabled users to the mediation server, and then a default route which will send everything to cisco. Basically, if you had 5 users enabled for OCS. You would have a rule on the gateway that had 1000-1005 with a destination of the mediation server. The second route would be * (any) with a destination of the PBX. This takes the load of modifying PBX configuration.

In this specific scenario, the media gateway could be a dialogic/NET device, or simply the PRI interface on the Cisco ISR.

It is important to note that with both of these scenarios you have full functionality of both systems at any given time. You can use your cisco phone to make and receive calls, or your OC client to make and receive calls. You can also take advantage of all conferencing, and other advanced functionality that OCS has to offer like remote access.


There may be some things that need clearing up in this, and I am open to some feedback, but this is really what I have been going off as a reference point for myself with these deployments. Another important factor is the retirement of Dual Forking and RCC in Wave 14 of OCS set to be released this year, existing OCS 2007 R2 implementations will be supported, however new deployments will not. This has made some companies forget about RCC implementations all together.

Live meeting and Conferencing Add-In Client Updates

Microsoft released a few updates yesterday for their Live Meeting client, the conferencing addin(still no office 2010 support) and for group chat. Grab em while they’re hot!

Live Meeting Client Update:

Conferencing Addin for Outlook:

Group Chat Update Package:

WinXnet Launches MSCERTIFIED.COM For Microsoft UC Certified Devices!

Portland, ME (July 29, 2009) – Today, Winxnet, Inc. announced the launching of their new online store, which sells Microsoft-certified telephones, headsets, and accessories. Winxnet now has one of the only web stores exclusively selling this optimized hardware.

This new online store, which is located at, targets organizations who have converted to the more cost effective Microsoft Unified Communications and provides them with a convenient and quick method of purchasing additional equipment. As the cornerstone of Microsoft’s Unified Communications, Office Communications Server is the platform for instant messaging, audio and video conferencing, and internet based telephone communications for businesses worldwide.

“We have seen organizations purchasing equipment which was not designed to work with this new cutting edge Microsoft communications suite,” said Chris Claudio, CEO of Winxnet, Inc. “Winxnet recognized the need in the marketplace for these users to find the right product which will work for them and their communications needs.”

As a Microsoft Gold Certified Partner and Voice Certified Partner, Winxnet is a leader in implementing Microsoft’s Unified Communications technology throughout New England and considers this new online store as the next step in providing complete service.

“As more of our own clients convert to Microsoft Unified Communications, we wanted to offer a place to easily purchase Microsoft-certified headsets, phones, conferencing equipment and accessories,” said Chris Claudio, CEO of Winxnet, Inc. “I am proud that our own e-commerce team designed and developed this site and that we have already seen sales since our beta launch.”

Winxnet has deployed Unified Communications throughout New England for organizations such as Stanley Works, Harvard Vanguard, Eastern Maine Healthcare Systems, Aetna, Boston Medical Center and Children’s Hospital Boston.

The new Winxnet online store features Microsoft-certified devices from leading communication manufacturers such as Jabra, Polycom, and Plantronics.

About Winxnet

Winxnet, founded in 1999, was created to provide customer-focused IT consulting services to organizations and businesses throughout southern Maine and has grown its operations to include offices in Waltham, Massachusetts and Chattanooga, Tennessee, employing more than 30 people. Winxnet’s clientele consists of both publicly and privately held businesses across a variety of industries, including retail, professional services, healthcare, hospitality, energy, and technology in addition to both non-profit and governmental organizations. Cultivating partnerships with clients has been a cornerstone of Winxnet’s success and continues to be a top business priority moving forward.

Winxnet is a premier Microsoft Gold Certified Partner and is headquartered in Portland, Maine. For more information, please visit

Gloria White
(866) 946-9638

Configuring Custom Exchange UM Auto Attendant Prompts (Part 1)

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.

Recording Custom Exchange UM Auto Attendant Prompts

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.

Exchange UM With OCS and Receiving Faxes- Success Story!

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