February – 2011 – B4Z.co.uk

Lync Server 2010 – Audio Test Service Issue

February 27, 2011 5 Comments

I recently experienced an issue when attempting to check the audio quality from a Lync 2010 client. When clicking the “Check” button under the enterprise voice tab of the client, I was greeted with a “Call has not completed or has ended” error. After some investigation it turned out this had occurred due to the primary SIP domain being renamed after the Lync Server installation had been performed and as a result the Test Call auto attendant still had the old SIP domain appended to it. To resolve this issue the following actions were performed:

1. Log on to your Lync server and open the Lync Server Management Shell. When the Management Shell opens type in the following command without quotations, “Get-CSAudioTestServiceApplication” and press return. You should now be presented with a service output and the key part we are looking for is the following:

OwnerUrn: urn:application:testbot
SipAddress: sip:R[email protected]

In my case, my primary SIP domain was no longer contoso.local, this was not even a secondary SIP domain. This ment that when attempting to perform a test call, the SIP address associated with the test bot could not be reached.

2. Now that you have confirmed the SIP address being used for the test call is incorrect, we can now look at a second section of the Get-CSAudioTestServiceApplication output in order to identify exactly what Active Directory attribute we need to modify. Under the identity section of the output you should see a similar string to the following:

Identity: CN={46577062-9cae-404b-b89c-a3d39511e4cc},CN=Application Contacts,CN=RTC Service,CN=Services,CN=Configuration,DC=contoso,DC=local

The CN={46577062-9cae-404b-b89c-a3d39511e4cc} attribute is the one which holds the SIP information for the test call bot. Now we know what attribute we need to modify, you can perform the following actions:

3. Logon to domain controller. From the Run dialog box type adsiedit.msc and click ok to open the ADSI Editor.

4. Right click ADSI Edit and then choose Connect To, and then select Configuration from the “Select a well known Naming Context list” and click ok.

5. Click on node CN={46577062-9cae-404b-b89c-a3d39511e4cc}, CN=Application Contacts, CN=RTC Service, CN=Service, CN=Configuration, DC=yourdomain, DC=local, and then right click this node and then select properties.

Note: Replace the “CN=46577062-9cae-404b-b89c-a3d39511e4cc” attribute that was identified in the Get-CSAudioTestServiceApplication output with the GUID for your organisation. The GUID’s specified are unquie to my Active Directory domain.

6. Choose the msRTCSIP-PrimaryUserAddress attributes, and change the domain part of value to sip:RtcApplication-0e0e407a-6283-4c93-99fa-c0e252b8af09@yourdomain.co.uk, opposed to your domain.local. Essentially the domain part of the attribute must match what ever your primary SIP domain is.

7. Log on to your Lync 2010 front end server and restart Audio Test Service. Once the service has been restarted, attempt a test call from Lync 2010 client.

That’s it, you should now be able to make test audio calls from Lync clients.

Remote Desktop Services – Windows XP Single Sign On

February 19, 2011 2 Comments

I recently experienced an issue with getting RemoteApp single sign on working from Windows XP workstations. When launching a published RemoteApp through either an .RDP or MSI file, users were prompted for authentication even though they had already authenticated on login. In order to stop this from occurring, the following actions were performed.

1. Ensure that the Windows XP workstation is running service pack 3 and ensure that the Remote Desktop Connection 7.0 Client is also installed. The Remote Desktop Connection 7.0 client can be obtained from here.

2. Install the Credential Security Support Provider (CredSSP) package. This enables credentials to be passed to target servers. The CredSSP package can be obtained from here.

3. Ensure that at least .NET Framework 3.5 SP1 is also installed on the workstation.

4. Configure a computer level Group Policy on a domain controller to enable delegating default credentials. A detailed explanation of how to configure the group policy object is detailed here.

5. The final step is to apply hotfix KB953760 which address a particular single sign on issue with Windows XP SP3 based workstations. The hotfix can be directly downloaded from here. When the hotfix has been applied reboot the workstation.

That’s it, you should hopefully now no longer be prompted for authentication when opening published RemoteApp’s on Windows XP SP3 workstations.

Remote Desktop Services – User Lockdown Policy

February 12, 2011 20 Comments

I recently deployed a small Windows Server 2008 R2 Remote Desktop Services environment and experience an issue where I could not hide the administrative tools folder that is inherited as a part of the default user profile. This meant that when a user connected to the session host (Terminal Server) they could see the administrative tools icon and associated MMC snap-in’s on the Start Menu. After trawling through all user based group policy objects, I realised hiding the administrative tools folder was not possible. To achieve this, I created a custom ADM template that could be imported into a Group Policy Object in order to hide the administrative tools entry. The steps I performed are featured below:

1. On a Windows Server 2008 R2 machine, with the Group Policy Management console installed, download and place the custom ADM file in the C:\Windows\inf. The ADM template (rdsadmintools.adm) can be download here, please right click the link and select Save Target As.

2. Edit your existing user lockdown Group Policy Object. Expand the user configuration, polices, then right click Administrative Templates and select Add/Remove Templates.

3. In the Add/Remove dialog box, select Add and then browse to the rdsadmintools.adm file and click ok followed by clicking close.

4. You should now see a “Classic Administrative Templates (ADM)” folder under the main Administrative Templates container. Double click this container and then double click the Remote Desktop Services container to reveal the GPO.

5. Double click the “Remove Administrative Tools From the Start Menu” GPO, click Enable and then using the drop down select box select “Off” and click ok.

Your all done, when logging in as a remote desktop services user you should now no longer be able to see the administrative tools start menu item.