A co-worker of mined had attempted to put in a Exchange 2013 recently – in which causing the UM Server not to work unexpectedly. Although after cleaning up the Exchange 2013, we notice that:

  • Dialing to Voice Mail doesn’t to work anymore
  • Dialing to the Exchange Auto Attendant & Subscriber access seems to just “dropped”
  • Miss call notifications & voice mail no longer arrives in the mailbox

From the Exchange Server, such error kept surfacing when an attempt is made through the Lync Client

The following UM IP gateways did not respond as expected to a SIP OPTIONS request.

Transport = TLS, Address = LyncPoolServer.domain.com Port = 5061, Response Code = 0, Message = This operation timed out


From the Lync Server:

Dial Plan Unknown

Dialplan [DialPlanName.domain.com] not recognized by routing application.

Cause: Dial plan does not exist, or Microsoft Lync Server 2013 does not have permission to read the relevant Active Directory objects.

Resolution: If the dial plan is valid, then run  exchucutil.ps1 in appropriate Exchange forest to give permission to Microsoft Lync Server 2013. If the dial plan is not valid, then clean up proxyAddress attribute for the affected users.


As we suspected that during the Exchange 2013 installation, some of the permissions may have been reset or altered, causing the issue above, so we went ahead and re-run the script of ExchUCUtil.ps1 from the Exchange 2010 Unified Messaging role server and restarted the services.

However, the first error still appears and to confirm this, we’d to check the Dial Plans on the Exchange UM Server:

Get-UMIPGateway | fl


Notice that the Port displays the value of 0 ; to solve this matter, we’d to manually assign the port number of 5061 to each Lync Server 2013:

Set-UMIPGateway -Identity LyncPool.domain.com -Port 5061

Next, a restart on the Microsoft Exchange Unified Messaging & Lync Server Front-End services will bring the Voice Mail back “alive”

Read the rest of this entry »

After running through the Hands-On Lab at the Lync Conference 2013 and also Microsoft MTC in Singapore, I’ve been itching to setup a unit of the SMART Interactive Board System or SMART Lync Room System from SCRATCH in which the unit is still not available in this region (Malaysia) – for now.

However, thanks to EP-Tec Solutions, I’ve manage to get an alternate model that leverages on SMART Meeting Pro that support Lync 2013 for interactive collaboration:


Assembling the unit was basically pretty straight forward – a moving wall stand, an interactive flat panel and some cables (VGA, HDMI & USB)


Before powering up the unit, I would recommend to prepare the machine to run on Windows 8.1 with Office 2013 Professional Plus (make sure to choose the Full Installation). Next, go to SMART Technologies download page and download SMART Meeting Pro 4.0


The download already comes with the SMART Meeting Pro Connector for Lync; if you’ve previously installed SMART Meeting Pro Connector for Lync, uninstall of the SMART Meeting software & components, make a reboot before you initiate the installation. Having both applications installed will cause the Microsoft Ink to go missing, which will cause the digital ink from smart unable to “write” onto the document.

Once the installation is completed, you should be able to see a grey side bar at the left at the screen



Once you’ve any of your Office Documents launched, Microsoft Ink will automatically be activated which allows you to write on the document. The system basically allows the document to be saved as a Native file format (docx, pptx & xlsx) after writing in the contents with the digital ink.

LRS_06        LRS_07

This is pretty useful when you perform an Online Meeting with Desktop Sharing is being initiated; however, take note that the Lync Whiteboard DOES NOT work with Microsoft Ink and you’ll need to use the given “Tools” from the whiteboard.


Microsoft had just released a public hot fix to remediate issues on iPad 2 running on iOS 7.1 where the Lync Client is unable to place or receive Audio & Video Calls

The Lync 2013 for iPad client cannot place or receive audio or video calls when the client is hosted on iPad 2 devices that are running iOS 7.1

The symptom doesn’t happen on Lync Client running on iPad Mini or the iPad Air, running on iOS 7.1

Kudos to the Lync Engineering team is identifying and resolving this matter!

Was just stumbling through the Windows Store and found a couple of cool apps on Lync

Lync Win8 Apps

Clockwise from the top left:

  1. Lync Handbook – a useful app for users whom are new to Lync
  2. Lync Pre-Call Diagnostic – a MUST for Lync Admin while troubleshooting Quality on Voice
  3. Shortcut Keys for Lync – a cool app that give you more productivity using Lync and your Keyboard (more than just touch!)
  4. Lync News – a RSS reader directly from NextHop


We’d two (2) offices physically located at two (2) different countries – SG & MY. A small scale call center is setup within the MY site to undertake Technical Support calls from locally & SG. Nonetheless, this Small Scale Call Center underlying is powered by Lync Server 2013 and Sonus UX1000 Media Gateway.

To give a better visualization of the setup, the layout looks like this:

Recently, the customer from SG site had given feedback that Inbound calls to the Call Center (+656212000) couldn’t get through, where calls are eventually dropped after a single ring tone.

Inbound RSG Failed - 02

However, calls to other SIP users (e.g. +6562120001) still works where the targeted SIP users’ Lync Client/Phone rings when an Inbound call is made. To investigate this, I’d lay down a few possibilities: The TDM-PBX, Media Gateway or the Enterprise Voice number could have been duplicated.

To start off, I’d to reproduced the issue by making an Inbound call and collect Traces from the Sonus Media Gateway & Mediation Server (which is Collocated with the Front-End Pool Server). Outcome from using Sonus Log Exchange (LX):

Inbound RSG Failed - 03

At the first 3 column indicates the calls is being attempted, from my mobile number of 60163735109 to the Call Center number (+65)6212000 and it seems that the signaling is working where the PBX throws the signal to Sonus UX1000 for processing. After which the Media Gateway will need to parse this signal to the Lync Mediation Server role. Further drilling into the log indicates that the Object/Resource wasn’t available:

Inbound RSG Failed - 04

At the Lync Server, using the options selected on Mediation Server, S4 & SIP Stack:

Inbound RSG Failed - 05

As the RGS Service was created under the MY’s Pool Server, the seems to have rejected the call, returning the message back to the UX1000 which caused the message of unavailable to be thrown back:

ms-diagnostics:  1038;reason=”Failed to connect to a peer server”;fqdn=”myfe.child.mydomain.com”;peer-type=”InternalServer”;winsock-code=”10061″;winsock-info=”The peer actively refused the connection attempt”;source=”myfe.child.mydomain.com”

During that moment, I thought of the most simplest method to resolve this issue is to recreate the entire RSG object as it was a weekend; so I went ahead to delete the Workflow, Queue & Group in sequences, when removing the object in Queue, there was a warning message that caught my attention:

Inbound RSG Failed - 06

I ran the command of the DFS Share: \\Child.MyDomain.com\MY-LyncP1F1\ and the folder returned empty, this is when I notice that my DFS mapping could’ve been removed “unintentionally” by another Administrator. To resolve this matter, I’d just to make sure that the correct shared path/directory is also configured under the DFS Management. For pre-caution, I republished the Topology Builder to make sure that the DFS path can be read by my Pool Servers.

Next, I’ve re-created the RSG services and all services had immediately came back online; the RSG folders & objects are also populated onto the File Store without any errors. To make sure that the RGS Service are working, another call was made from my mobile and the calls was routed based on the configured Workflow & Queues.

Conclusion: the RGS objects in the File Store are required to be accessibility as part of the reference when calls are being made, else calls will be dropped:

Inbound RSG Failed - 07

Recently, I’d a couple of request to migrate some of my customer from Google Apps (mainly Gmail) to Microsoft Office365. As using the Out-of-the-Box migrator within the Exchange Online (IMAP) migrator doesn’t seem to be working, I’d an opportunity to conduct a trial using MigrationWiz instead.

To do so, it only takes a few simple steps to get the migration working.

1. First of all, we’ll need to delegate full rights to an Account that we’ll be using for the migration, for simplicity, I’ve used back the Portal Administration. Log onto the Microsoft Online Portal and head over to the Exchange Admin Center. Anchor to the user that will be receiving the migrated email contents and grant full rights to the Administrator:

O365MigWiz - 01

2.  Access the User Mailbox Properties & select Mailbox Delegation. Under Full Access, add in the Administrator Account that will be used to migrate the contents on behalf of the user


3. Once done, login to MigrationWiz Portal and create a Connector, to link between Google Mail & Exchange Online, using the following configuration:


  • Create a Project Name (e.g. Company Name – dd/MM/YYYY)
  • License Category: Commercial (Note: this is also subjected to the license that was purchased)
  • Source Settings
    • Service Provider: Google
    • Source Type: Google App/Gmail
  • Destination Settings
    • Service Provider: Microsoft Office 365
    • Destination Type: Microsoft Office 365
    • Access using Admin Credential: Checked
    • Admin Username: Username@domain.onmicrosoft.com
    • Password: password

4. Select the Items that is to be migrated across & click on Create.


You can also further customized how the migration should behave, such as notification and the period of the contents that is to be migrated across:


Similar to other migration (On-Premises), the process runs background without any Administrative attention required; hence, it is recommended to have the following notification configured for each migration project:

  • Successful Migrated Mailboxes
    • The email address of the source mailbox being migrated
    • The email address of the destination mailbox being migrated
    • To the MigrationWiz email account that was registered OR Office 365 Admin Email Address
  • Failed Migrated Mailboxes
    • Office 365 Admin Email Address

You may only want to notify the users that the mailbox has been migrated when it is successful so the users would know that the contents has been successfully copied into Office 365 account; on the other hand, the failed mailboxes needs to attended by the Administrators and we shouldn’t be bothering the users – shouldn’t we? :)

In almost every migration activities, organizations are concerns on how fast and how quick can the migration be completed, hence choosing the nearest Data Center for the migration is very crucial. To determine that, you’ll need to check where are the email contents placed at Google App. For Microsoft Office 365, make sure the mailbox are selected to the correct country when assigning the Exchange Online license:



You can also create a filter of the duration of the contents and which folders to excluded in the process of migrating the mailboxes


You can also convert Gmail’s labels to Microsoft’s Exchange/Outlook’s Category model:


Save the configured settings but don’t start the migration yet.

Logon to the Gmail Account that is planned for the migration, take down the total number of items under the Inbox:


Now go back to MigrationWiz to initiate the migration:


  • Source Mailbox
    • Put in the source email address under Gmail (in most cases, it should be the original email address)
    • Username would likely be the same as the previous entry = your source email address
    • Password
  • Destination Mailbox
    • The Office 365 Mailbox Account: username@domain.onmicrosoft.com

Confirm the Advance Settings (you may choose to further customized or use back the default values that was configured earlier) and proceed with the migration.

The migration is now ready to be migrated


Start the migration process by clicking on the  Cloud Icon O365MigWiz_11a  and MigrationWiz will then start to verify the credentials at Google Mail which was input earlier:


Once it is successful, the mailbox will then start the migration



When the migration completes, you get to view the overall statistics of the migration:


O365MigWiz - 16 O365MigWiz - 17 O365MigWiz - 18

Now, the final step is to verify the contents that has been migrated over to Office 365

O365MigWiz - 19

It appears that the 10 years ago dilemma is reoccurring, where updates from Microsoft are not Quality Assured before releasing to the public. In the most recent Office 2013 Security releases, received by my Admin via Intune, running on Windows 8 64-bit installed with Office 2013 32-bit, the right pane was “blank” once the system reboots after a successful installation:

Outlook 2013 Blank Right Pane


After running by the Internet, it appears that the Sept 2013 was the cause and the update has been pulled back. Although there’re several workarounds to this, I still prefer to have my Right Pane back as it is.

First of all, uninstall the following Office Security Updates:

  1. Security Update for Microsoft Office 2013 KB2810009
  2. Update for Microsoft Office 2013 KB2817630

Reboot the system, download and install KB2817347; take note this Hotfix needs to be requested and couldn’t be located from Windows Update. Upon completing the installation, reboot and you’ll get back the Right Pane.

I hope after this incident, Microsoft Quality Assurance Team for the Windows Update will validate any upcoming releases before releasing it to the public or History shall repeat itself (e.g. BSODs during the Windows 2000 days)

In a recent Response Group Service (RGS), call forwarding is required if the call is unattended after 20 seconds. However, when the call doesn’t get routed to the next number after the timeout.

Using the OCS Logger, this is what has been captured:

RGS Transfer Fail 01

Based on the third trace a SIP 2.0 403 Forbidden error message was thrown with a diagnostic message:

ms-diagnostics: 12001;reason=”User Policy does not contain phone route usage”;source=”MY-FE.MyDomain.com”;UserUri=”sip:MY-Helpdesk@MyDomain.com”;appName=”OutboundRouting

It appears that the account doesn’t have sufficient rights to route/forward the call out on behalf of the caller. To address this issue, the following commands needs to be executed:

Get-CsApplicationEndpoint sip:MY-Helpdesk@MyDomain.com| Grant-CsVoicePolicy -PolicyName “MyCall Policy”

Once the PowerShell has been execute, wait for the next User Replicator to take effect and the calls are now able to be routed to the specified destination! :D

From my Previous article, after swapping a faulty disk from the Front-End Pool Server, the server refuses to go online and kept hitting onto the BSOD (Blue Screen of Death), causing the system to keep rebooting by itself before it manage to reach the Desktop part. Despite attempts to repair the Operating System, the system just couldn’t come back online.

Hence, I’ve decided to start fresh (since we’re running on an EE Pool with SQL as the back-end), after rebuilding the entire system and to have the Lync Services up and running, to my amazed none of the users within the environment was able to connect to the server and behavior was:

Unable to Sign In to Lync 01

Although the Machine has been joined to the Domain, the Lync client still prompts for another round of authentication

Unable to Sign In to Lync 02

After putting in the correct password, the Lync client still indicates that the User credential is incorrect and doesn’t allow any users to logon.

That led me into suspecting whether the previous activity that I’d did to repair the RTC had led to this incident. To confirm this, I’d created another dummy account and sip enabled it – problem still persists.

The following commands has also been issued towards both existing and the new dummy account that it has been SIP enabled:

Get-CSUser -Identity “sip:AccountName@mydomain.com”

Identity : CN=AccountName ,OU=MyOU, DC=Child, DC=MyDomain, DC=com
VoicePolicy : Some Call Policy
VoiceRoutingPolicy :
ConferencingPolicy :
PresencePolicy :
DialPlan :
LocationPolicy :
ClientPolicy :
ClientVersionPolicy :
ArchivingPolicy :
ExchangeArchivingPolicy : Uninitialized
PinPolicy :
ExternalAccessPolicy :
MobilityPolicy :
PersistentChatPolicy :
UserServicesPolicy :
HostedVoiceMail :
HostedVoicemailPolicy :
HostingProvider : SRV:
RegistrarPool : Pool1.child.mydomain.com
Enabled : True
SipAddress : sip:Accountname@mydomain.com
LineURI : tel:+XXXX
EnterpriseVoiceEnabled  : True
ExUmEnabled : True
HomeServer : CN=LcServices,CN=Microsoft,CN=1:17,CN=Pools,CN=RTCService,CN=Microsoft,CN=System,DC=mydomain,DC=com
DisplayName : Account Display Name
SamAccountName : AccountSAMName

However, when attempting to register both accounts using the following cmdlet:

Test-CSRegistration -UserSipAddress AccountName@mydomain.com -TargetFQDN Pool1.child.mydomain.com


Target Fqdn : Pool1.Child.MyDomain.com

Result : Failure

Latency : 00:00:00

Error Message : 404, Not Found

Diagnosis : ErrorCode=1003,Source=sip.chassasia.com,Reason=User does not exist, destination=mydomain.com Microsoft.Rtc.Signaling.DiagnosticHeader

While using DBAnalyzer to capture the existing accounts, the returned value was:

>dbanlayzer.exe /sqlserver:Pool1.child.mydomain.com\RTCLOCAL /report:user /user:sip:AccountName@mydomain.com


User : jamesooi@mydomain.com
Resource Id : 99
Database Type : Usc Db
Registrar Pool : NULL
Usc Pool : NULL
Display Name : NULL
Enabled : False
OptionFlags :  0×0
ArchivingFlags :
ForwardingUrl : NULL
MovingAway : False
Contact Version : 1104

I was almost stunned when returned values from the database was almost all NULL – which means none of the information which has been published by Active Directory are written into the RTC database; which means either the Active Directory or the SQL Database(s) had went faulty.

Hence, further investigation needs to be proceed to identify the root cause:

  1. OCS Logger Tool

Enable the following traces allows us to observed the actual process when the user attempts to sign-in:

  • SIPStack
  • S4
  • Web Infrastructure
  • User Services

Output under the traces window:

Unable Sign in to Lync 003

Line 1: —-Odbc State: 42000, Severity: 11, Native: 50010, Sproc: DbRaiseError, Line: 20, Sql State: 1, Message: [Microsoft][SQL Server Native Client 11.0][SQL Server]###50010:CertStoreGetPublishedCert:jamesooi@mydomain.com is not found in this database.—-

Line 2: ^^^^ CertStoreGetPublishedCert sproc execution failed : ExecHr = [hr=S_OK], NativeError = [50010], NativeErrorSeverity = [11], NativeErrorLineNumber = [20], NativeErrorSqlState = [1], OdbcSqlState = [42000], ErrorText = [[# [Microsoft][SQL Server Native Client 11.0][SQL Server]###50010:CertStoreGetPublishedCert:jamesooi@mydomain.com is not found in this database. #]]^^^^.

Line 3: ( 0000000007105720 ) Replying with 403 hr[S_OK] Ms-diag[4005] AuthzId [jamesooi@mydomain.com] Reason[]

Output under the Messages window, there’ll plenty of 401 & 403 Unauthorized errors:

Unable Sign in to Lync 004

Based on the error messages, this leads to the next component within Lync – the SQL Server Database Service

2. SQL Profiler

Using the SQL Profiler is to identify whether information between Lync & SQL are communicating. As we needed to re-produced the problem, another account was created from Active Directory and Enable at Lync Server Control Panel. In this trace:Unable to Sign in to Lync 005

Line 1: Beginning of the trace – Lync Server 2013 is connected to the SQL Server instance and execute commands

SP : StmtStarting – raiserror (@Message, @Severity, @_State, @SprocName, @_Param1, @_Param2, @_Param3)

Line 2: Error message thrown out by the application, SQL was not able to locate the entry in the database

SP: User Error Message – ###50010:ReportUserData:danny@mydomain.com is not found in this database

Line 3: Traces ends

SP : StmtCompleted – raiserror (@Message, @Severity, @_State, @SprocName, @_Param1, @_Param2, @_Param3)

Thus, SQL has indicated that Lync Server 2013 is communicating nicely and properly with SQL Server 2012. But this left us dead-witted: so if Lync Server 2013 is interacting with SQL Server as expected, why isn’t Lync server able to write or pick up the correct information?

Finally, we ran another attempt of forcing the User Database to be updated, hoping that it’ll give us a different results. When we ran the Get-CSUserDatabaseState the following output was generated:

Identity : UserDatabase:MY-DB02.child.mydomain.com

Online   : True

And subsequently, we ran the Get-CSUserReplicatorConfiguration and this was the only results returned:

Identity : Global
ADDomainNamingContextList : {dc=mydomain,dc=com}
ReplicationCycleInterval  : 00:01:00

In which I realized that my child domain wasn’t part of the User Replicator Configuration event any longer, probably the information had went missing/corrupted during the repair of the RTC database (needs to be confirmed).

So, we went ahead to add the child domain entry into the User Replicator Configuration:

Set-CsUserReplicatorConfiguration -Identity global -ADDomainNamingContex tList @{Add=”DC=child,DC=mydomain,DC=com”}


And the next thing, using the Test-CSRegistration cmdlet, all users were able to log on to the system successfully!

Test-CsRegistration -UserSipAddress jamesooi@mydomain.com -TargetFqdn  MY-LYNCP1.child.mydomain.com

Target Fqdn : MY-LYNCP1.child.mydomain.com

Result : Success

Latency : 00:00:02.6059438

Error Message :

Diagnosis :

It took us almost 3 - 4 days to look into this issue, assuming that Lync & SQL server interaction had went wrong, and it appears that it was just a User Replicator Configuration had went missing, causing that the SIP enabled user information was not able to be seen and replicated by Lync Server 2013 itself.

About few days ago, disaster had struck upon and one of our Lync 2013 Front-End server Hard disk running on RAID-1 failed. Before making the switch, I notice some of the newly SIP enabled users were not able to sign-in, although there were no errors raised under the Event Log, I thought it may be good just to confirm that all of the database(s) from the Front-End Pool Server & SQL Back-end Server are running in good condition.

Using the SQL Management Studio, I’ve connect to the Front-End Pool Server PoolFQDN\RTCLOCAL and just to notice that the RTC database has a (Suspect) mode mark beside it, in which it had raise my suspicion that the problem that I’m facing was due to this matter. Hence, in order to make the swap of the hard disk, I’d repair the database using the following command:

EXEC sp_resetstatus ‘RTC’


DBCC CheckDB (‘RTC’)




For each line, these are the actions that is being perform:

  1. Reset the suspect flag
  2. Set the database to emergency mode so that it becomes read only and not accessible to others
  3. Check the integrity among all the objects
  4. Set the database to single user mode
  5. Repair the errors that ALLOWS DATA LOSS
  6. Set the database to multi user mode, so that it can now be accessed by others

Note that line #5 repairs the database but data loss will likely occurred, so far I’ve tried using other syntax but didn’t work out as expected, hence, this was my final resort (Use at your own risk).

After the Query was completed, I’d confirmed all services are still functional and no event errors was raised, we’ve decided to replaced the faulty disk with the new unit and perform the reboot. Disaster await for me on the next article…


Get every new post delivered to your Inbox.

%d bloggers like this: