I recently deployed a Microsoft Lync Server 2013 infrastructure for a customer running Microsoft Exchange Server 2007 SP3, and while this version of Exchange Server is supported it should be noted there are a few additional amendments that need to made in order to make UM Auto Attendant key mappings to Lync extensions work correctly. Following the typical UM integration through the use of OCSUMUtil.exe and ExchUMUtil.ps1, all Unified Messaging functionality seemed to be working correctly, including dial by extension. It wasn’t until a key mapping was added to an Auto Attendant to transfer a call to a specific Lync extension, did I see an issue. When calling the attendant and pressing one for example, which was directed to extension 319, the Unified Messaging service would produce the following error and the attendant would tell the caller “The call could not be transferred”.
As you can see, there is not a specific amount of detail to go on and researching this particular Event ID suggested this was an error that could pertain to a number of issues. On researching further however, I noted the following from the TechNet article on integrating Lync Server 2013 with Exchange Unified Messaging:
If you are using a version of Exchange that is earlier than Microsoft Exchange Server 2010 SP1, you must enter the fully qualified domain name (FQDN) of the corresponding Exchange Unified Messaging (UM) SIP dial plan in the Lync Server 2013 dial plan Simple name field. If you are using Microsoft Exchange Server 2010 SP1 or latest service pack, this dial plan name matching is not necessary.
In order to resolve the key mapping issue the following was performed.
1. Connect to the Lync Server 2013 control panel and click Voice Routing and then select the Dial Plans tab.
2. Double click the “Global” dial plan to edit it and in the Simple Name dialog box, remove the word Global and replace it with the name of your Exchange Unified Messaging dial plan followed by your internal Active Directory domain name. For example, if my UM Dial Plan name was “DefaultUM” and my internal domain was “company.local”, I would enter DefaultUM.company.local into the Simple Name field.
3. Click OK and then commit the change, you will then need to wait a few moments for the change to take affect before trying the key mapping again. It should also be noted that in the Global dial plan you will need sufficient normalisation rules for the key mapping to work when transferring to an extension. In my case the dial plan now looked like the following:
That’s it, hopefully your Auto Attendant key mapping issues to Lync extensions will now be resolved.
I had a customer inform me over this Christmas period that they were not receiving any inbound e-mail from external sources, even though internal e-mail flow was fine as well as outgoing. I performed a quick inbound e-mail test at testexchangeconnectivity.com to discover that their Exchange 2007 installation on Windows Small Business Server 2008 was producing the following NDR error:
Delivery of the test message failed.
Additional Details: The server returned status code 452 – Insufficient system storage. The server response was: 4.3.1 Insufficient system resources
From looking at the error it can be concluded that this issue was definitely related to system storage. What had actually happened was that free disk space on the Windows system drive had dropped below a 4 Gigabyte threshold and as a result the Exchange Back Pressure feature had disabled inbound e-mail messages, as there was no longer sufficient disk space for the mail submission queue to function. This was further confirmed by reviewing event ID’s 15002 and 15006 in the Windows application event log. As I was struggling to free disk space on the system drive, I decided to move the Exchange Mail Submission Queue database to a separate disk where I had plenty of free resource. To perform this, I carried out the following procedure:
1. On a separate disk volume create a new folder structure, for example, D:\Microsoft Exchange\Queue.
2. Open the Exchange Management Shell and type the following command:
I was presented with an issue around one month ago that was very interesting. An Exchange 2007 environment where public folders could be seen and used by Outlook clients but could not be viewed in the Public Folder Management Console or be queried through Windows Powershell. This is an extremely poorly documented issue on the internet, and there are many posts on several forums and blogs asking the same question but unfortunately with no resolution. I have found that public folders cannot be viewed in the Public Folder Management Console if one of the following conditions is true.
1. An Exchange 2003 to Exchange 2007 migration has been performed and the public folder hierarchy structure was not moved to the new Exchange organisation.
2. Public folder database corruption has occured and the database has been repaired using ESEUTIL.
If either of these conditions are true, and you cannot view system of default public folders in the Exchange Public Folder Management console you will need to recreate your storage group and public folder database. If you have tried to remove your public folder database following Microsoft TechNet guidelines you will be aware that attempting to remove it’s replica’s using Powershell will not work. To remove the database, perform the following actions:
1. Backup all of your public folders manually. This can be performed by creating a new archive PST on an Outlook client and then copying each public folder to the archive location. In addition, make a note of all e-mail addresses that are associated with mail enabled public folders. This PST will come in handy later if your database has suffered corruption.
2. Open the Exchange Management Console, expand the Organization container and click Mailbox. From the mailbox options, select the Offline Address Book tab, right click the offline address book and select properties. Select the distribution tab and then uncheck “Enable public folder distribution” as shown in the screenshot below. This removes the OAB association with the public folder database we want to delete.
3. In the Exchange Management Console, dismount the public folder database. Navigate to the folder where your database is contained, right click the EDB database file and make a copy of this to an alternate location. If your database is not corrupt, this will come in handy later.
4. Open ADSI Edit, if you are running Windows 2008 this will be pre-installed and can located under the servers Administrative Tools. If you are running Windows 2003 however you will need to download and install the Windows Server 2003 Support Tools from here.
5. In ADSI Edit connect to the configuration Naming Context. When this is displayed expand configuration and navigate to CN=Services -> CN=Microsoft Exchange -> CN=Your Organisation Name -> CN=Administrative Groups -> CN=Exchange Administrative Group (FYDIBOHF23SPDLT) -> CN=Folder Hierarchies. Right click the Folder Hierarchies container and select delete. Click OK to delete all sub objects of this container also. This action removes the heirarchy attribute for the public folder database we want to delete, this attribute will be automatically recreated at later stage.
6. In the same ADSI window, expand CN=Servers -> CN=Your Server Name -> CN=InformationStore. Highlight container CN=Second Storage Group, right click this container and select delete. Click OK to delete all sub objects of this container also.
7. Open the Exchange Management Console and expand the Server container and click Mailbox. You will now notice that your Second Storage Group and Public Folder Database are no longer listed. In the actions pane of the Mailbox window click “New Storage Group” and follow the creation wizard. Once the storage group has been created click “New Public Folder Database” and follow the creation wizard. Please note, if an error occurs during the last step of the wizard relating to mounting the new database, click finish and then manually mount the new database yourself. If your interested you will now see through ADSI Edit that the two containers we deleted earlier have now been recreated.
8. Expand the Organization container and click Mailbox. From the mailbox options, select the Offline Address Book tab, right click the offline address book and select properties. Select the distribution tab and then check “Enable public folder distribution”, in effect the reverse action of step two. If this is not performed any down level Outlook clients, such as 2003, will not be able to utilise the OAB.
9. Now the new database has been created you can attempt to either restore the database you backed up in step 3 or restore the public folders individually from an Outlook client using the PST created in step one. To decide which method you need to use, open the Exchange Management Console, select the Server container and then click Mailbox. Dismount the public folder database, then right click the database and select properties. Place a check next to the ” This database can be overwritten by a restore” option as shown in the screenshot below.
10. Browse to the file location of the new public folder database and then copy the backed up database from step 3 so that the existing database is overwritten. Return to the Exchange Management console and mount the database. If you cannot see public folders in the Public Folder Management Console, your database has suffered corruption. Unfortunately performing integrity, repair and defragment operations through ESEUTIL do not resolve this problem. If the database is corrupt you will need to perform steps 1-9 of this guide again, and then use your PST file to restore the public folders. Please note, if the PST method is used you will need to mail enable any public folders that previously had this functionality again. Public folder permissions however, are kept intact when restoring via PST.
While this is a slightly lengthy process, removing the storage group, database and it’s related Active Directory attributes will resolve this issue.
