Fixing the “We didn’t find an audio device, which you need for calling” issue with Lync 2013 client in a Citrix XenDesktop 5.6 Virtual Desktop

I’ve been working with a client that had two new offices opening in London with HP t610 thin clients as desktops to access the XenDesktop 5.6 environment I built last year at their Bermuda office.  This weekend was the actual deployment and we noticed that the Lync clients within their VDIs wasn’t fully functional which then kicked off a 5 hour troubleshooting exercise on Saturday and another 5 hours on Sunday until we got it going.  As I’ve been extremely busy lately with multiple projects on the go and haven’t been blogging as much, I felt it was important to set aside a bit of time today to just dump all of the information I have in my head that was required to get this going.  Sorry about format as it’s not very organized so I’ll follow up with a proper post demonstrating the process step by step.

Problem

You have the Lync 2013 client installed onto a Windows 7 Citrix XenDesktop virtual desktop and you noticed that the client correctly finds the Video Device as the Citrix HDX Web Camera and it works as expected:

… but when you click on the Audio Device, you see the following:

We didn’t find an audio device, which you need for calling

If you have one already, try checking Windows Device Manager to make sure it’s installed and working.

Learn More

The problem appears to be that the Lync 2013 client does not like or see the Citrix HDX Audio device:

One of the more prominent solutions in Citrix forum posts is to remove the Citrix remote USB bus and Citrix remote USB host controller as such:

 

Citrix remote USB bus

Warning: You are about to uninstall this device from your system.

Delete the driver software for this device.

Citrix remote USB bus controller

Warning: You are about to uninstall this device from your system.

Delete the driver software for this device.

Once removed, restart the Lync 2013 client and the audio device will now get picked up:

Video and audio calls work as expected but as we all know, if the desktop is shutdown or restarted, these drivers would get reinstalled and if they’re not present, USB redirection of, say, USB flash drives does not appear to work.  I suppose it is possible to use the Delete the driver software for this device. checkbox is an option but I prefer not to permanently remove the device or the driver.  The Citrix blog post here: http://blogs.citrix.com/2013/04/05/tech-preview-of-xenapp-support-for-the-lync-2013-vdi-plug-in/ has a lot of comments at the bottom with users discussing the issue but appears to not have a resolution.

Another interesting article from TechNet demonstrating how Lync 2013 should work in a VDI desktop can be found here:

Update: Microsoft Lync 2013 in a Virtual Desktop Infrastructure
http://blogs.technet.com/b/nexthop/archive/2012/07/31/microsoft-lync-2013-preview-in-a-virtual-desktop-infrastructure.aspx

Troubleshooting steps out there:

Removing Power Saving Mode for USB Root Hub

One of the suggestions found here: http://forums.citrix.com/thread.jspa?threadID=332025

… and here: http://social.technet.microsoft.com/Forums/lync/en-US/30ec9d70-2cca-40be-b9dc-be7763e3530a/lync-2013-client-no-audio-device-detected suggests to uncheck:

Allow the computer to turn off this device to save power

… in the device manager for each and every USB Root Hub and Generic USB Hub but the problem with this solution is that the option is not available for the Citrix remote USB bus and Citrix remote USB host controller.  While this option is usually available for the USB Root Hub, the VDI does not have the proper driver installed for this component:

Device status

This device is not working properly because Windows cannot load the drivers required for this device. (Code 31)

Furthermore, the post appears to be for an actual physical desktop.

Solution

As per the following Citrix article, there appears to be a few steps outlined by Citrix to get this to work:

XenDesktop 7, XenApp 6.x and Citrix Receiver 4.0 Support for Microsoft Lync 2013 VDI Plug-in
http://support.citrix.com/article/CTX138408

Step #1 – Update Citrix Receiver on the HP t610 thin client

Finally, I went ahead to check the t610 thin client’s receiver and noticed that it was version 13.x.x.xx so upgraded it to 14.

Step #2 – Enable EnableMediaRedirection In Lync 2013 Server

Begin by logging onto the Lync 2013 Server and use the:

Set-CsClientPolicy -EnableMediaRedirection $TRUE

… on the global policy or whatever policy you use for your users. 

Step #3 – Install Microsoft Lync VDI Plug-in

Install the Microsoft Lync VDI Plug-in onto the HP t610 Windows embedded thin client from here:

Microsoft Lync VDI 2013 plugin (32 bit)
http://www.microsoft.com/en-us/download/details.aspx?id=35457

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

**Note that if you receive a The installation of this package failed. error while installing the VDI plugin, extract the installer with:

lyncvdi.exe /extract:c:\lync

Then run:

setup.exe /admin

… to bring up the office customisation app, close it then run:

setup.exe

… to get it to install.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

Step #4 – XenDesktop VDA version 7

Uninstall the Citrix XenDesktop 5.6 VDA agent on the pooled desktop’s master image, installed XenDesktop 7 VDA and pushed it out.

Step #5 – Enable Remote Recording

Another interesting blog post I found which I’m not sure whether is needed but configured it anyway was the following:

Lync deployment: using Virtual Desktops (VDI)
http://itbasedtelco.wordpress.com/2013/06/17/lync-deployment-using-virtual-desktops-vdi/

… that demonstrated how to configure this for RDS which included an additional registry key to add:

REG ADD “HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp” /v fDisableAudioCapture /t REG_DWORD /d 0 /f

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

Step #6 – Configure additional registry keys to specify internal and Lync Server 2013’s external server address:

With all of the above done, Lync now will now display the message:

Lync is trying to use your local audio and video

… but then displays:

Lync is not yet connected to Local Audio and Video Devices

What was necessary to get Lync to connect to the local audio was to manually add the following registry keys to the thin client:

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\15.0\Lync]

"ConfigurationMode"=dword:00000001"

"ServerAddressInternal"="yourLyncServer.domain.local"

"ServerAddressExternal"="yourExternalEdge.domain.com"

Step #7 – Install RDP Updates

Ensure that the following RDP updates are installed onto the thin client:

• KB2592687: Description of the Remote Desktop Protocol 8.0 update for Windows 7 SP1 and Windows Server 2008 R2 SP1, released October 24, 2012, and its prerequisite
• KB2574819: An update is available that adds support for DTLS in Windows 7 SP1 and Windows Server 2008 R2 SP1, released October 23, 2012

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

After all the steps have been completed, proceed with restarting the thin client.  The Lync 2013 VDI plugin should successfully pair up with the Lync client once the thin client has been restarted as you will notice a Lync 2013 prompt to enter your Sign-in address, User name and Password.  Both audio and video should work from the Lync client now.  If you’re still having issues, review the applications installed onto the thin client and remove any packages such as ones for the webcam or audio devices that may conflict with the VDI plugin.

I’ll be preparing a more detailed post on how to configure all of this when I get more time.  Hope this helps anyone out there who may be looking for more information on getting this to work.

Outlook 2010 client unable to connect to newly deployed Exchange Server 2013

Problem

You’ve deployed a new green field deployment of Exchange Server 2013 in an environment, applied cumulative update 2 but notice that when you attempt to connect with an Outlook 2010 client, you notice that the configuration passes the Establish network connection step, then the Search for username@domain.com server settings step but fails at the Log on to server step with the the following error:

The connection to Microsoft Exchange is unavailable. Outlook must be online or connected to complete this action.

Clicking on the OK button will display the Microsoft Exchange window with the Microsoft Exchange server field filled with a:

GUID number followed by @domain.com

… and the Mailbox field with:

=SMTP:username@domain.com

Changing the *Specify the authentication method for external clients to use when connecting to your organization from:

Negotiate

… which Exchange gives the warning:

warning

Microsoft Exchange versions earlier than Exchange Server 2013 do not support the Negotiate client authentication method. Connectivity to public folders and mailboxes hosted on earlier versions may be affected.

… to:

NTLM

… does not resolve the issue.

Solution

I’m not sure why but one of the first few results from searching

outlook 2010 unable to connect to exchange server 2013

… was the following KB:

Outlook is unable to connect to Exchange 2013 public folder or auto-mapped mailbox
http://support.microsoft.com/kb/2839517

… but the hotfix did not resolve my issue.

After trying multiple suggestions from various source I found from searching without any luck, I decided to first update Outlook 2010 RTM (no service pack version 14.0.4763.1000) with SP1 (version 14.0.6029.1000) which unfortunately did not fix the issue.  I then proceeded to download Outlook 2010 SP2, applied it and noticed that I was then able to connect.  The following is a screenshot of the version that was able to connect to the newly deployed Exchange 2013 server:

Version: 14.0.7106.5001

 

A bit of a frustrating problem so I hope this post would be able to save someone the frustration and some time.

Attempting to download Lync Server 2013 topology throws the error: “Cannot open database "xds" requested by the login. The login failed.Login failed for user 'someDomain\someAdmin'. ---> System.Data.SqlClient.SqlException: Cannot open database "xds" requested by the login. The login failed.Login failed for user 'someDomain\someAdmin'.”

Problem

You’re logged onto the Lync Server 2013 server and attempt to use Topology Builder to download the Lync topology:

… but receive the following error:

Cannot open database "xds" requested by the login. The login failed.Login failed for user 'someDomain\someAdmin'. ---> System.Data.SqlClient.SqlException: Cannot open database "xds" requested by the login. The login failed.Login failed for user 'someDomain\someAdmin'. 

The following is the complete output:

Downloading topology...
Attempting to perform the InitializeDefaultDrives operation on the 'FileSystem' provider failed.
System.Management.Automation.CmdletInvocationException: Cannot read topology. Verify that the topology data is accessible. ---> Microsoft.Rtc.Common.Data.SqlConnectionException: Cannot open database "xds" requested by the login. The login failed.Login failed for user 'someDomain\someAdmin'. ---> System.Data.SqlClient.SqlException: Cannot open database "xds" requested by the login. The login failed.Login failed for user 'someDomain\someAdmin'.   at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)   at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)   at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)   at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)   at System.Data.SqlClient.SqlInternalConnectionTds.CompleteLogin(Boolean enlistOK)   at System.Data.SqlClient.SqlInternalConnectionTds.AttemptOneLogin(ServerInfo serverInfo, String newPassword, SecureString newSecurePassword, Boolean ignoreSniOpenTimeout, TimeoutTimer timeout, Boolean withFailover)   at System.Data.SqlClient.SqlInternalConnectionTds.LoginNoFailover(ServerInfo serverInfo, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance, SqlConnectionString connectionOptions, SqlCredential credential, TimeoutTimer timeout)   at System.Data.SqlClient.SqlInternalConnectionTds.OpenLoginEnlist(TimeoutTimer timeout, SqlConnectionString connectionOptions, SqlCredential credential, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance)   at System.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, SqlCredential credential, Object providerInfo, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance, SqlConnectionString userConnectionOptions)   at System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, DbConnectionPoolKey poolKey, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection, DbConnectionOptions userOptions)   at System.Data.ProviderBase.DbConnectionFactory.CreatePooledConnection(DbConnectionPool pool, DbConnectionOptions options, DbConnectionPoolKey poolKey, DbConnectionOptions userOptions)   at System.Data.ProviderBase.DbConnectionPool.CreateObject(DbConnectionOptions userOptions)   at System.Data.ProviderBase.DbConnectionPool.UserCreateRequest(DbConnectionOptions userOptions)   at System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, UInt32 waitForMultipleObjectsTimeout, Boolean allowCreate, Boolean onlyOneCheckConnection, DbConnectionOptions userOptions, DbConnectionInternal& connection)   at System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal& connection)   at System.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal& connection)   at System.Data.ProviderBase.DbConnectionClosed.TryOpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions)   at System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 retry)   at System.Data.SqlClient.SqlConnection.Open()   at Microsoft.Rtc.Common.Data.DBCore.PerformSprocContextExecution(SprocContext sprocContext)   --- End of inner exception stack trace ---   at Microsoft.Rtc.Management.Store.Sql.XdsSqlConnection.ReadDocItems(ICollection`1 key)   at Microsoft.Rtc.Management.ScopeFramework.AnchoredXmlReader.Read(ICollection`1 key)   at Microsoft.Rtc.Management.WritableConfig.AnchoredXmlSchemaCache.get_Item(ScopeClass scopeClass)   at Microsoft.Rtc.Management.Xds.ManagementConnection.GetAnchoredXmlWrapperFromReader(SchemaId schemaId)   at Microsoft.Rtc.Management.Xds.ManagementConnection.ReadTopologyXml(TypedXml& typedXml, AnchoredXml& anchoredXml)   at Microsoft.Rtc.Management.Xds.ManagementConnection.ReadTopology(TypedXml& topologyXml, Topology& topology)   at Microsoft.Rtc.Management.Xds.XdsCmdlet.<ReadTopology>b__5()   at Microsoft.Rtc.Management.Internal.Utilities.DeImpersonator.<>c__DisplayClass1.<Run>b__0()   at Microsoft.Rtc.Management.Internal.Utilities.DeImpersonator.Run[T](Boolean dropImpersonation, Func`1 func)   at Microsoft.Rtc.Management.Xds.XdsCmdlet.ReadTopology()   --- End of inner exception stack trace ---   at System.Management.Automation.Internal.PipelineProcessor.SynchronousExecuteEnumerate(Object input, Hashtable errorResults, Boolean enumerate)   at System.Management.Automation.Runspaces.LocalPipeline.InvokeHelper()   at System.Management.Automation.Runspaces.LocalPipeline.InvokeThreadProc()
Failed
Finished

Another common error is the following:

Download Current Topology

Topology Builder could not copy the topology from the Central Management store. Cannot read topology. Verify that the topology data is accessible.

Solution

I’ve been called a few times over the past year for this error and realized that the more prominent explanations out there on the internet right now is that this can happen during an install of Lync Server 2013 where errors might be thrown and the solution is to reinstall.  While this may be true because a failed install may leave an XDS database that’s incomplete, the calls I’ve received in the past are usually from administrators who have had Lync Server 2013 running in their environment but noticed this error even though the environment is working as expected.  The cause for this error in my past experience with the indicated symptoms is that the administrator is using an account that does not have permissions to the XDS database (just as the error indicates).

I believe SQL Server 2000 was the last version of SQL that automatically assigned local administrators sysadmin rights in the database and while I know many administrators typically enter domain admins in as administrators during SQL Server 2005, 2008 and 2012 installs, larger organizations do not.  This is why the companies I see this happen most are larger ones with dedicated SQL administrators that do not like regular Active Directory administrators to have full sysadmin rights to their precious SQL servers.

The database in question here is the XDS database stored on either a backend database server if you’re using the Enterprise Edition of Lync Server 2013 or the local SQL install if you are using the Standard Edition.  Taking a peak into the XDS database’s Security node displays the following accounts that are assigned some permissions to the XDS database:

• domain\RTCUniversalConfigReplicator
• domain\RTCUniversalReadOnlyAdmins
• domain\RTCUniversalServerAdmins
• localServer\RTC Local Administrators
• localServer\RTC Local Config Replicator
• localServer\RTC Local Read-only Administrator

Now I will admit that I don’t usually work with large clients that have individual teams for various Microsoft products but there are the odd ones that do so the Lync administrator may not have any permissions to the SQL database hosting the Lync databases.  What I find interesting is that either of the following is happening for standard edition installs:

1. The Lync installer for standard edition adds the account used to install Lync as an administrator as a sysadmin for the local SQL instance.
2. SQL Server Express automatically adds the account installing it as a sysadmin for the SQL instance.

I haven’t actually really looked into this but I do believe it’s a result of #2. To cut a long story short, what basically needs to be done here is to either grant the account that is having problems downloading the topology sysadmin to the database or db_owner rights to the XDS database.  Adding the account to any of the accounts listed above (i.e. domain\RTCUniversalServerAdmins) does not work and adding the account to the CSAdministrators group doesn’t either.

Attempt to apply cumulative update database updates to Lync Server 2013 standard server fails with: “Error: An error occurred: "Microsoft.Rtc.Management.Deployment.DeploymentException" "Cannot find any suitable disks for database files. You must manually specify database paths.”

Problem

You attempt to apply cumulative update database updates to a Lync Server 2013 standard server with the cmdlet:

Install-CSDatabase -ConfiguredDatabases -SqlServerFqdn <standardLyncServerFQDN> -Verbose

… but it fails with the error:

WARNING: Install-CsDatabase failed.
WARNING: Detailed results can be found at
"C:\Users\administrator.SomeDomain\AppData\Local\Temp\2\Install-CsDatabase-6b80904
b-3c18-43c0-8568-d09c4d0406c1.html".
Install-CsDatabase : Command execution failed: Cannot find any suitable disks for database files. You must manually specify database paths.
At line:1 char:1
+ Install-CsDatabase -ConfiguredDatabases -SqlServerFqdn
lyncstd01.someDomain ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~
    + CategoryInfo          : InvalidOperation: (:) [Install-CsDatabase], Depl
   oymentException
    + FullyQualifiedErrorId : ProcessingFailed,Microsoft.Rtc.Management.Deploy
   ment.InstallDatabaseCmdlet
PS C:\Users\administrator.SomeDomain>

Opening the install html log in the folder C:\Users\administrator\AppData\Local\Temp\2\Install-CsDatabase-6b809… show the following:

Error: An error occurred: "Microsoft.Rtc.Management.Deployment.DeploymentException" "Cannot find any suitable disks for database files. You must manually specify database paths.

Solution

I find that most people who come across this error would immediately think that the upgrade process is unable to locate the Lync databases and that additional information needs to be Install-CSDatabase cmdlet.  Unfortunately, that is usually not the solution as this is usually due to insufficient drive space on the drive where the database is located.  In this example, the database is stored on the C drive and it currently only has 12GB of free drive space:

Most forum posts suggest that you need at least 20GBs but the first time I encountered this problem, I noticed that 16GB appeared to be sufficient:

Unable to delete Exchange Server 2010 mailbox database with no arbitration mailboxes shown

Problem

You attempt to remove a mailbox database but receive the following error:

The mailbox database '<Mailbox Database Name>' cannot be deleted.

--------------------------------------------------------
Microsoft Exchange Error
--------------------------------------------------------
The mailbox database 'SomeName - Mailbox Database' cannot be deleted.
SomeName - Mailbox Database
Failed
Error:
This mailbox database contains one or more mailboxes, mailbox plans, archive mailboxes, or arbitration mailboxes. To get a list of all mailboxes in this database, run the command Get-Mailbox -Database <Database ID>. To get a list of all mailbox plans in this database, run the command Get-MailboxPlan. To get a list of archive mailboxes in this database, run the command Get-Mailbox -Database <Database ID> -Archive. To get a list of all arbitration mailboxes in this database, run the command Get-Mailbox -Database <Database ID> -Arbitration. To disable a non-arbitration mailbox so that you can delete the mailbox database, run the command Disable-Mailbox <Mailbox ID>. To disable an archive mailbox so you can delete the mailbox database, run the command Disable-Mailbox <Mailbox ID> -Archive. Arbitration mailboxes should be moved to another server; to do this, run the command New-MoveRequest <parameters>. If this is the last server in the organization, run the command Disable-Mailbox <Mailbox ID> -Arbitration -DisableLastArbitrationMailboxAllowed to disable the arbitration mailbox. Mailbox plans should be moved to another server; to do this, run the command Set-MailboxPlan <MailboxPlan ID> -Database <Database ID>.

--------------------------------------------------------
OK
--------------------------------------------------------

You attempt to use the Arbitration switch to see if there are any arbitration mailboxes left on the database but the output does not show any:

[PS] C:\Windows\system32>Get-Mailbox -Database "SomeName - Mailbox Database" -Arbitration

Solution

In situations where you have a forest with multiple domains and the mailbox database you’re unable to delete is located in a child domain, you will need to use the:

Set-ADServerSettings -ViewEntireForest $true

… cmdlet prior to running:

Get-Mailbox -Database "SomeName - Mailbox Database" -Arbitration

… in order to view the arbitration mailboxes such as SystemMailbox and FederatedEmail:

[PS] C:\Windows\system32>Set-ADServerSettings -ViewEntireForest $true
[PS] C:\Windows\system32>Get-Mailbox -Database "SomeName - Mailbox Database" -Arbitration
Name                      Alias                ServerName       ProhibitSendQuota
----                      -----                ----------       -----------------
SystemMailbox{1f05a927... SystemMailbox{1f0... abcmbx01         unlimited
SystemMailbox{e0dc1c29... SystemMailbox{e0d... abcmbx01         unlimited
FederatedEmail.4c1f4d8... FederatedEmail.4c... abcmbx01         1 MB (1,048,576 bytes)

[PS] C:\Windows\system32>

With the arbitration mailboxes now shown, proceed with moving them to another database with the cmdlet:

Get-Mailbox -Database “<Some Mailbox Database Name>” -arbitration | New-MoveRequest -TargetDatabase “<SomeOther Mailbox Database Name>” 

… and then try to delete the mailbox database again:

More information about the Set-AdServerSettings cmdlet can be found at the following TechNet article:

http://technet.microsoft.com/en-us/library/dd298063(v=exchg.141).aspx

Enabling TLS for Exchange Server 2010

I’ve recently been asked to troubleshoot why TLS wasn’t working for an Exchange 2010 server even though the obvious settings have been configured.  What I’ve found was that most administrators tend to perform only 1 of 2 steps and therefore left wondering why TLS isn’t offered by the Exchange server so this post serves to outline the steps so that I can direct anyone who runs into this issue to this blog post.

How do you know whether your Exchange server is performing opportunistic TLS?

The easiest way to determine whether the Exchange server is performing opportunistic TLS is to simply telnet to the hub transport server via port 25:

telnet localhost 25

**Note that I’m logged directly on the Exchange server in the screenshot above so please substitute localhost with either the external MX record or the name / IP of the hub transport server if you’re coming from the internal network.

Execute the command:

ehlo

… and look for 250-STARTTLS in the output:

Notice how the screenshot above does not contain the 250-STARTTLS output which means this Exchange server is not going to accept TLS connections.

Step #1 – Turn on “Enable Domain Security (Mutual Auth TLS)” or enable “DomainSecuredEnable” setting:

The settings:

1. Enable Domain Security (Mutual Auth TLS)
2. DomainSecuredEnable

… are actually the same as one of them is configured through the Exchange Management Console and the other is through PowerShell. 

Option #1 - Exchange Management Console:

To enable the setting in the EMC, navigate to Microsoft Exchange On-Premises –> Server Configuration –> Hub Transport and select the appropriate receive connector that receives email from the internet:

Open up the properties of the receive connector and navigate to the Authentication tab, then check off Enable Domain Security (Mutual Auth TLS):

Option #2 - PowerShell:

The second way of enabling the setting is to launch PowerShell then use the Set-ReceiveConnector cmdlet.  You can also check to see if the setting is enabled by using the:

Get-ReceiveConnector <Connector Name> | FL

… and scroll to the DomainSecureEnabled setting:

… or execute:

Get-ReceiveConnector <Connector Name> | FL DomainSecuredEnabled

… to only display that setting.

To enable the setting, execute:

Set-ReceiveConnector <Connector Name> -DomainSecureEnabled $true -AuthMechanism TLS

Note how the screenshot above now displays the DomainSecureEnabled property as being True.

If you open up the properties of the receive connector, you’ll see that the Enable Domain Security (Mutual Auth TLS) setting is checked off:

Step #2 – Assign a certificate to the SMTP service:

I find most administrators tend to miss step 2 which is to assign a certificate to the SMTP service so ensure that you have a certificate with the CN or an entry in the SAN that matches the MX to A record name, then use the:

Get-ExchangeCertificate

… cmdlet to list the certificates:

Copy the Thumbprint and then execute the following cmdlet:

Enable-ExchangeCertificate -thumbprint <thumbprint of certificate> -services:SMTP

Note that I already had a certificate assigned so was prompted to overwrite the existing certificate.

Now when you telnet to the Exchange server, you should see the 250-STARTTLS option:

Cisco UCS Server Configuration Utility hangs at “Initializing the kernel…” process on a Cisco UCS C220 M3 server

Problem

You’ve downloaded the Cisco UCS Server Configuration Utility to perform a Windows Server install on a new Cisco UCS C220 M3 server but noticed that it hangs at the:

Initializing the kernel…

… for a long time and never continues ending with a black screen.

Solution

I’m not sure if this is common across all Cisco UCS C servers but the cause of this issue at one of my clients was that he was using a USB Lenovo DVD-ROM drive for the install.  After trying several older version of the Cisco UCS Server Configuration Utility without any luck, I went ahead and connected through the CIMC and used the KVM console Virtual Media tab to mount the ISO and noticed that the problem went away.

Not sure if it’s the DVD-ROM drive because I didn’t have any other DVD-ROM drive available to test but I hope this post will save another person a bit of time.

Unable to install Windows Server 2008 R2 onto a Cisco UCS C Series C220 M3 server with Microsoft media

As easy as it may seem to Cisco UCS administrators, I’ve found that people who are new to UCS typically run into bare metal Windows Server 2008 R2 installs on to Cisco UCS C Series servers.  I’m writing this blog post because I received a call yesterday from a client who purchased 4 new Cisco UCS C220 M3 servers, took a Windows Server 2008 R2 media and ran into the following issue where the RAID driver isn’t present in the media and therefore prompted the message:

Select the driver to be installed.

A required CD/DVD drive device driver is missing. If you have a driver floppy disk, CD, DVD, or USB flash drive, please insert it now.

Note: If the Windows installation media is in the CD/DVD drive, you can safely remove it for this step.

What the client did was go ahead to download the 3.5GB ISO package containing the UCS drivers and try to load it at this prompt.

UCS administrators would know this is not the right approach so my first response to them was to download the Unified Computing System (UCS) Server Configuration Utility to perform the install:

 

The example I gave them for what this does was that it’s the same as HP SmartStart for HP servers.

I was curious as to whether they did any searches and was told they did but couldn’t find anything so I hope this post will help anyone in the future who may come across this problem.  The following is an old post I wrote that demonstrates what the Unified Computing System (UCS) Server Configuration Utility process looks like:

Installing Windows on a Cisco UCS C Series server with Cisco UCS Server Configuration Utility
http://terenceluk.blogspot.com/2011/07/installing-windows-on-cisco-ucs-c.html

New Lync Server 2013 deployment’s Front-End service on Windows Server 2012 fails to start with multiple errors in event logs

Problem

You’ve deployed a new Lync Server 2013 deployment on a Windows Server 2012 server but noticed that immediately after successfully installing the services, issuing and assigning certificates, the Lync Server Front-End service fails to start:

Reviewing the Lync Server event logs show the following events:

• Error – 12308
• Error – 32201
• Information – 32189
• Error – 30941
• Error – 32175
• Error – 32178
• Warning – 32174
• Information – 32189
• Error – 32178
• Information – 32189
• Error – 32178
• Information – 32189
• Error – 30988
• Error – 32178

… and so on:

The details to the events are as follows:

Event ID Error 12309:

A component could not be started. The service has to stop.

Component: Live Communications User Services Error code: 80004005!_HRX! (Unspecified error

!_HRM!)

Event ID Error 32201:

Failed to flush data to backup store.

Cause: This may indicate a problem with connectivity to local or backup database or some unknown product issue.

Resolution:

Ensure that connectivity to local and backup database is proper. If the error persists, please contact product support with server traces.

Event ID Error 32189:

The following Fabric service for routing groups have been closed:

{8EC325CB-B512-587D-9D03-E940E7CC1490}

{8EC325CB-B512-587D-9D03-E940E7CC1490}

{8EC325CB-B512-587D-9D03-E940E7CC1490}

{8EC325CB-B512-587D-9D03-E940E7CC1490}

{8EC325CB-B512-587D-9D03-E940E7CC1490}

{8EC325CB-B512-587D-9D03-E940E7CC1490}

{8EC325CB-B512-587D-9D03-E940E7CC1490}

.

Event ID Error 30941:

Initialize failure.

Error code: 80004005

 

Event ID Error 32175:

Server is being shutdown because fabric pool manager could not complete initial placement of users.

Cause: This can happen if insufficient number of Front-Ends are available in the Pool.

Resolution:

Ensure that all the Front-Ends configured for this Pool are up and running. If multiple Front-Ends have been recently decommissioned, run Reset-CsPoolRegistrarState -ResetType QuorumLossRecovery to enable the Pool to recover from Quorum Loss and make progress.

Event ID Error 32178:

Failed to sync data for Routing group {8EC325CB-B512-587D-9D03-E940E7CC1490} from backup store.

Cause: This may indicate a problem with connectivity to backup database or some unknown product issue.

Resolution:

Ensure that connectivity to backup database is proper. If the error persists, please contact product support with server traces.

Event ID Warning 32174:

Server startup is being delayed because fabric pool manager has not finished initial placement of users.

Currently waiting for routing group: {8EC325CB-B512-587D-9D03-E940E7CC1490}.

Number of groups potentially not yet placed: 1.

Total number of groups: 1.

Cause: This is normal during cold-start of a Pool and during server startup.

If you continue to see this message many times, it indicates that insufficient number of Front-Ends are available in the Pool.

Resolution:

During a cold-start of a large Pool it can take upto an hour for the placement process to finish as it needs to populate all the Front-End databases with data from the Backup Store. If the Pool is running and the Front-End is just started, this is normal for some time. If this repeats for a long time, ensure that all the Front-Ends configured for this Pool are up and running. If multiple Front-Ends have been recently decommissioned, run Reset-CsPoolRegistrarState -ResetType QuorumLossRecovery to enable the Pool to recover from Quorum Loss and make progress

You’ve tried using the cmdlet Reset-CsPoolRegistrarState -ResetType QuorumLossRecovery but the front-end service continues to fail to start.

Solution

For those who have came across one of my previous posts:

Lync Server 2013 Edge server replication issues on Windows Server 2012
http://terenceluk.blogspot.com/2013/04/lync-server-2013-edge-server.html

Lync Server Access Edge service fails to start with: “… service-specific error code -2146762487”
http://terenceluk.blogspot.com/2013/05/lync-server-access-edge-service-fails.html

… will know that I’ve ran into a few challenges with Lync Server 2013 Edge servers on a Windows Server 2012 operating system.  As noted in the posts above, Windows Server 2012 is more stringent when it comes to trusted certificates and actions such as mistakenly putting an intermediate certificate in the trusted root certificate store can cause replication to stop working between the Edge and front end server.  What’s unfortunate about these issues with having certificates in the incorrect / wrong store is that the event logs doesn’t mention anything remotely suggesting that the issue has to do with certificates.  In this front-end server example, the issue was caused by legacy GPOs placing intermediate QuoVadis certificates into the incorrect store as shown in the following screenshot:

Note that the certificates such as QuoVadis Issuing Certification Authority 2 and the others highlighted in red are all Intermediate Certificates but placed into the Trusted Root Certification Authorities:

Having worked with various clients’ Active Directory over the past few years, I’ve noticed that something like this happens quite often so the solution is to remove the GPO that is putting the certificate into the Trusted Root Certification Authorities store and then manually deleting or move the certificates on the Lync Server to the appropriate store.  The front end server will start once the certificate issue is resolved:

In case anyone is looking for a solution to automate removing these certificates from other servers, have a look at one of my old posts here:

How to remove a trusted Certificate Authority from “Trusted Root Certification Authorities” certificate store on workstations in an Active Directory domain
http://terenceluk.blogspot.com/2012/05/how-to-remove-trusted-certificate.html