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:

LRS_01

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

LRS_02

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

LRS_03

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

LRS_04

LRS_05

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

O365MigWiz_02

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

O365MigWiz_03

  • 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.

O365MigWiz_04

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:

O365MigWiz_05

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:

O365MigWiz_06a

O365MigWiz_06

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

O365MigWiz_07

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

O365MigWiz_08

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:

O365MigWiz_09

Now go back to MigrationWiz to initiate the migration:

O365MigWiz_10

  • 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

O365MigWiz_11

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:

O365MigWiz_12

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

O365MigWiz_13

O365MigWiz_14

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

O365MigWiz_15

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

Output:

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

Output:

User : jamesooi@mydomain.com
————————————————
Resource Id : 99
Database Type : Usc Db
Registrar Pool : NULL
Usc Pool : NULL
GUID : NULL
SID : 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”}

Update-CSUserDatabase

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’

ALTER DATABASE RTC SET EMERGENCY

DBCC CheckDB (‘RTC’)

ALTER DATABASE RTC SET SINGLE_USER WITH ROLLBACK IMMEDIATE

DBCC CheckDB (‘RTC’, REPAIR_ALLOW_DATA_LOSS)

ALTER DATABASE RTC SET MULTI_USER

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…

Was running a Lync Server 2010 Training (MOC 10533A) throughout this week and in order to use the licenses within the MOC Labs, the date & time needs to be reverse (back to the future!)

As most of the lab machines are cloned using the actual date & time, Hyper-V creates a certificate the moment the Virtual Machine is being created and started; only during the class, the date & time will be reverted back in time. When attempting to Connect (or literally remote control) the VM, the status of the VM will show as ‘Starting…’ and subsequently throw with errors:

An Error Occurred while attempting to start the selected Virtual Machine(s):

‘Virtual Machine Name’ could not initialized

Could not initialize machine remoting system. Error: ‘Element not found.’ (0×80070490).

Could not find a usable certificate. Error: ‘Element not found.’ (0×80070490).

To resolve this matter, follow the steps below:

  1. Start > Run > MMC
  2. Add the Certificates Snap-In
  3. Select Service Account
  4. Under the Select Account to Manager, select Hyper-V  Image Management Service
  5. Complete the Snap-In Wizard
  6. Expand the Certificates under Personal Category
  7. Notice the certificate generated has been created ‘for the future’ (assuming you’re suppose to revert the date & time to 2010, the certificate should display as invalid because it was created at 2013)
  8. Delete the Certificate(s)
  9. Go to the Services Console and Restart all Hyper-V Services

Now, go back to the Hyper-V Manager and the VMs should be able to be ‘Connected’ right now.

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: