Lync 2010 reports lync cannot connect to the exchange server

While this hasn't been causing us any problems (yet), I am planning to use Lync 2010 with Exchange 2010/Outlook calendar integration shortly and until all Exchange connectivity issues are resolved, this can't be achieved.



The Problem

After the Lync 2010 client has been open for around a half hour or so, a red error box appears in bottom right hand corner of the client, clicking on the error displays a message.

Exchange Connection Error - Click to display details.

and then after clicking that error we see a further error message.

Lync cannot connect to the Exchange server. Lync will attempt to retry the connection.

Investigating the problem

To get some more information you can hold CTRL and right click on the Lync 2010 icon in the notifications area and select the "Configuration Information" window. This window shows how Lync is setup and potentially will display any problems.

On my configuration I noticed the "EWS Internal URL" and "EWS External URL" were both blank, and the "EWS Information" had a status of "EWS not deployed". I know it certainly is deployed, but just to be sure I verified it was configured and there was a instance of EWS under my Exchange 2010 IIS instance.

What I also noticed after browsing through my registry, was that the "Autodiscover" key was totally missing our of my Lync configuration. The following key should exist, replace <SIP> with your sip account name, so for me it was jtrevaskis@domain.edu.au

HKCU\Software\Microsoft\Communicator\<SIP>\Autodiscovery

If the Autodiscovery registry key does not exist, then your Lync client has not been able to connect to the Autodiscovery service of outlook and resultantly it cannot enumerate the locations of critical Exchange services such as EWS that will seed the Lync client information.



But I already have the Autodiscover service configured perfectly

Well that is what I thought too! What I didn't realize is that when I originally configured Lync I set my client domain as my external domain. It is important to identify what your SIP domain is, so when you log into Lync, what address is used, for me it was my external email domain and this is the root cause of my problems.

Internal Domain: domain.internal
External Domain: domain.edu.au

So while I have my DNS records for autodiscover.domain.internal A and _autodiscover._tcp.domain.internal SRV configured perfectly, the Lync client is actually looking for for autodiscover services at autodiscover.domain.edu.au and _autodiscover._tcp.domain.edu.au

I ran a quick Wireshark session to confirm my suspicions and within a few minutes of starting the Lync client I was seeing DNS lookup requests for _autodiscover._tcp.domain.edu.au



The Solution

I don't really want to offer Autodiscover services to the outside world and I don't want to publish _tcp records onto my external DNS services. After all, my Lync clients are being used internally only, so I wanted to find a solution that would work internally without disclosing too much information.

I got it! OK this is a little bit of a hack, but it works perfectly for me, and ensures none of my internal DNS records need to be published on the internet.

1. I created a _tcp.domain.edu.au zone on my internal DNS servers.

2. In my newly created zone, I added a SRV record by right clicking the zone and selecting "Other Records" and then "SRV".

3. I entered _autodiscover as the service type, _tcp as protocol, 443 as port number and the FQDN of my Exchange IIS service instance that is offering my Autodiscover and EWS services.

That is it, simple as that! I restarted my Lync client and within 5 minutes the "Configuration Information" window was displaying the correct EWS URL's and the HKCU\Software\Microsoft\Communicator\<SIP>\Autodiscovery registry key had been created and fully populated.

If you want to use Lync externally or already have external _tcp DNS records, then you can easily point your clients to an external EWS server and achieve the same result.

The main requirement is that a _autodiscover._tcp SRV record points directly to your Exchange IIS instance that is hosting EWS. As long as you achieve that, be it via a hack like mine, or publishing external _autodiscover._tcp records and pointing them to an external EWS instance, it should work.



Other issues worth investigating

If you are still having issues, it would be worth checking your Exchange 2010 IIS instance to ensure Autodiscover and EWS are configured and that you can reach the Autodiscover service via https://domain/Autodiscover/Autodiscover.xml to which you should see some XML random returned.

Also ensure that when you visit you Exchange IIS instance https://  in a web browser via the same FQDN you entered in your DNS SRV record above, you receive no certificate errors. If there are any certificate errors you will need to resolve them before Lync will be able to reach the Autodiscover service.

Upgrading from Citrix PVS 5.6 SP1 to PVS 6.0

Citrix recently released their latest version of Provisioning Services (PVS), version 6.0, with a number of new features.

The most substantial of these is the vDisk Update Management, allowing the administrator to control patch management with SCCM and windows updates automatically. This involves having a virtual desktop host dedicated to recieving updates and changes, and then PVS can move the vDisk automatically into a development or production environment according to your requirements.

PVS now also supports thin provisioning of vDisk changes, so instead of copying that 25GB vDisk and then making changes on it, a VHD differencing disk is created, which can then be slipstreamed back in the original when everything is just right. This makes sense as it will decrease space and time required to make new versions of vDisks.

The last major update is a DR feature for vDisk distribution, allowing you to easily distribute a vDisk across multiple PVS servers or sites.



The Upgrade Process

1. Stop the PVS streaming service from the windows services MMC snap-in.

2. Make a backup of the PVS SQL database. Dont skip this step!

3. If you are using PVS in conjunction with Xendesktop (XD) and you don't have any high availability, put your XD pools into maintenance modes.

4. Un-install your current PVS version and then reboot.

5. After the reboot, simply insert your PVS DVD or ISO and run the PVS_Server_x64.exe (or PVS_Server.exe if you are on 32bit OS) from the "Server" directory.

6. Follow the prompts until the installation is completed, then follow the PVS configuration wizard. If all goes well you will not need to configure anything at all, you can accept all the defaults.

7. Install the PVS console by running the PVS_Console_x64.exe (or PVS_Console.exe) from the "Console" directory on the DVD.

The installation should be complete, but if you are using XenDesktop you may need to do some troubleshooting to resolve problems that may have occured during the uninstallation and upgrade.



Problems and Resolutions

After I upgraded my PVS to 6.0 I was able to launch the console without a problem, but I was unable to use the 'XenDesktop Setup Wizard' and when I tried open the Desktop Studio console I received the following error message.

The Windows PowerShell snap-in 'Citrix.Broker.Admin.V1' is not installed on this machine.

 

It seems that when I uninstalled PVS 5.6 SP1, it may have inadvertently removed or damaged some Desktop Studio power shell snap-ins.

The resolution is very simple though, pop in your Xendesktop 5.0 or 5.5 DVD or ISO and reinstall the following two files.

\x64\DesktopStudio\PVS PowerShell SDK x64.msi

\x64\Citrix Desktop Delivery Controller\Broker_PowerShellSnapIn_x64.msi

When launching the above msi files, firstly click uninstall, then re-run them and install them both. After completing this process your Desktop Studio and PVS console should work perfectly.

3000MHz with 8GB of ram (4x4GB) just for fun

After the recent Geil competition where I took 16GB of ram to 2720 MHz to win the competition, I decided to have a play with the same GSKILL Trident 2000 MHz 8-9-8-24 kit in a 8GB dual channel configuration.

The result after a couple of hours of tweaking was a cool 3000 MHz!

Setup
2x GSKILL Trident 2000 8-9-8-24 4GB
Gigabyte X58A-UD7 rev 2.0 with GOOC2010 bios
Intel 980X Gulftown CPU
Single Stage @ -50
Western Digital Velicoraptor 600GB SATA3
Windows 7 32bit SP1



Results

CPU-Z validation link

Click on the below photo to expand it.

I am starting to play with my Corsair GTX6 sticks on the same set-up now with hopes of breaking 3400 MHz.

Attempting to make Virtual Desktops with old hardware attractive to the end user

As I have mentioned on a number of previous blog posts, I am not happy with any of the cheaper thin endpoints for delivering video across the network, they simply don't work well. Of course you can spend $600 and get a thin client powerful enough to deliver video but after adding a keyboard, mouse, monitor and licensing, you might as well buy a traditional thick client.

We have migrated a slice of our environment to Xendesktop using old hardware as clients and it has been working exceptionally well from a technical perspective, but its downfall is that people are apprehensive to use "old looking" endpoints. Some of this can be addressed with education, "Yes I understand it looks like the laptop you were using 5 years ago, but actually..", but there is still that aesthetic aspect


While aesthetics is not important in some areas, it does become more of an issue in rooms where we might have external companies or individuals visiting. One of these areas is a presentation room in our Library, which often accommodates external visitors and staff meetings. We have decided to install thin clients in this room and progressively move them out to the rest of the Library, but as this room is used by 3rd parties, aesthetics is a consideration.

The Library computers are nearly exclusively used for Internet and Microsoft Office, with a small percentage of other applications being used making them PERFECT candidate for thin clients.



The Solution

We are using old laptops for this room so we quickly decided we needed to purchase a new monitor, mouse and keyboard. This added another layer of complexity as the laptop lid needs to be opened to access the on/off switch (as the switch is inside the laptop lid). Our solution was to have stands made with a laminate finish that matches the existing benches in the room. The units hide the laptop and most of the cables while acting as a stand for the monitor to sit.

You can see in the above photo we have had a opening made at the back for the cables to be routed though and another opening for the laptop screen to "pop-up" though.

 

A headphone jack and USB port have been built in to the front, to provide easy access for the end user. When you sit in front of this system you totally forget you are at a thin client.

 Above is an image of the fully configured system running.

I wouldn't change very much if I was to rebuild them. Perhaps increase the rear recess by about 2CM to allow easier access to the on/off button.



Total Cost

Custom built stand - $40
Cables - $10
Monitor - $155
Keyboard/Mouse - $20
Server slice + Licensing - $320

Total = $545

Traditionally a desktop build for business or education will cost about $1000 per unit, so in comparison a build like this where you reuse old systems can significantly decrease total cost of ownership, not to mention savings from decreased management.

Our plan is to cycle old laptops through these areas, so every couple of years as more laptops are decommissioned they can be installed as thin clients.

If you have any of your own similar solution I would love to see them!

James Trevaskis wins HWBOT 16GB memory clocking challenge with 2720 MHz

Overclocking competition overlords HWBOT recently held a memory overclocking competition in conjunction with manufacture Geil. The competition consisted of 3 rounds including Super PI, lowest memory clock and highest memory clock with 4x 4GB modules.

I decided to enter the 16GB of ram challenge, I have played around with clocking 16GB of memory in the past but not seriously pushing the frequency. I chose the GSKILL Trident 2000 MHz 8-9-8-24 kit as I have tested this kit vigorously in 2x4GB 8GB configurations and easily achieved 2500 MHz.

Starting with the P55 platform and an Intel Lynnfield 870 CPU, I was only able to achieve 2480 MHz with the timings of 9-11-9-27. At this point I thought I was done as P55 is known as the best memory clocking platform.

I quickly moved to X58 and this is where the real magic happened. I relaxed the memory timings to 11-15-15-31, TRFC at 200 and loosened the B2B latency. I started up my single stage cooling, which is an evaporator based cooling solution (like a fridge for your CPU), which set my CPU at -50 degrees Celsius. Instantly I hit 2600 MHz, wow this is great. After playing with some more of the sub timings I was at 2720 MHz before I knew it.

What I had achieved in 6 hours with my P55 setup I was passing within an hour on my X58 system. I put this down to the power of the IMC on Gulftown. Sure P55 has traditionally been great at memory clocking, but this is because uncore isn't a limitation. I believe X58 is probably the stronger platform for clocking any high density memory modules as it is a easier to drive 3 modules in triple channel and the 4th in its own channel than 2 modules over 2 channels as per P55.


My Setup:
4x GSKILL Trident 2000 8-9-8-24 4GB
Gigabyte X58A-UD7 rev 2.0 with GOOC2010 bios
Intel 990X Gulftown CPU
Single Stage @ -50
Western Digital Velicoraptor 600GB SATA3
Windows 7 32bit SP1


Results:

CPU-Z Validation

I made a quick YouTube video of the setup.

USB Keyboard not responding, being detected as HID-compliant mouse

I recently rebooted a Windows 7 workstation that had no known pre-existing problems and observed a very obscure situation. After the system rebooted, the USB keyboard no longer worked. After gaining access to the desktop via the mouse and on screen keyboard I went into control panel to troubleshoot the error.



The Problem

At first I looked right past the HID-compliant mouse with the yellow exclamation mark next to it as I was troubleshooting a keyboard error not a mouse. After I removed the keyboard and re-plugged it in, it was clear that the system was indeed detecting the USB keyboard as a HID-compliant mouse. Windows has put a yellow exclamation on the mouse icon as it has been unable to start the device, this is of course because it is trying to use a mouse driver for a keyboard.

First I tried simply rebooting and even using different keyboards but neither worked.



The Resolution

Now before you go playing in the registry deleting values makes sure you know what you are doing and have made backups. I am not responsible for any damage you may do to your system.

I resolved this problem by clearing out the registry keys that Windows uses to store settings on the keyboard, mouse and HID-compliant devices. The down side to clearing out theses values is next time you plug in your favourite USB device, it will take some time to detect and install.

The keys in question are:

HKLM\SYSTEM\CurrentControlSet\Control\Class\{745A17A0-74D3-11D0-B6FE-00A0C90F57DA}- HID-compliant Devices

HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E96B-E325-11CE-BFC1-08002BE10318} - Keyboard

HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E96F-E325-11CE-BFC1-08002BE10318} - Mouse

You need to clear out all the keys storing information on devices you have previously plugged into the system. You can do this by going to each of the above keys with regedit and deleting all the 4 digit keys, but leave the Properties key alone. So in the below example of the keyboard key, I would delete the 0000, 0001, 0002 and 0006 keys.

Then you need to unplug your keyboard and reboot, once the system has rebooted plug the keyboard back in and wait for it to be detected, hopefully your keyboard is now working again!

If not you may need to dig a bit deeper, try another keyboard or worst case scenario, rebuild your system.

Troubleshooting the Sharepoint 2010 User Profile Service Application

The Sharepoint 2010 User Profile Service (UPS) application allows the Sharepoint administrator great flexibility and is a "must have" feature if you are taking your Sharepoint to the next level.

Unfortunately UPS has a dark side that too many administrators have to face at one time or another, more often than not it is related to the "Forefront Identity Management Service" and the "Forefront Identity Manager Synchronization Service" service.



Some Tips

• Upgrade to Sharepoint 2010 SP1 and the August 2011 CU at before attempting to resolve problems. Both of these updates resolve a number of issues that might impact the User Profile Service application.
• Don't ever try to change the "Forefront Identity Manager Service" or "Forefront Identity Manager Synchronization Service" settings manually from the Services MMC snap-in. It simply doesn't work as SP needs to do a great deal of configuration.
• Sharepoint can be super slow, sometimes you need to wait 10-15 minutes for things to happen, so when you click start and nothing happens, wait 15 minutes then check again.
• If you are re-creating the User Profile Service application, it is a good idea to use different names for the databases, the service application itself and the application pool. This will ensure there are no conflicts with any old settings that may be floating around in your Sharepoint configuration or registry.
• Be IISRESET "happy". It is a good idea to perform IISRESET's after major parts of the setup process. I normally follow a pattern such as: Start/Create the service, wait 10 minutes, IISRESET, next step. This will ensure all of Sharepoint is "on the same page" before moving forward to the next step of the process.

Possible Issues and Resolutions

Problem:
After starting the "User Profile Synchronization Service" from Central Administration only the "Forefront Identity Manager Synchronization Service" starts, or both services fail to start.

Resolution:
If you don't have too much already setup in the UPS or it is your first time setting it up, it can be much easier to delete the UPS, stop the Synchronization services and then recreate it, than mess around. See my rebuild process below.


Problem:
"Forefront Identity Manager" source logs an Event ID 3 in event logs.

.Net SqlClient Data Provider: System.Data.SqlClient.SqlException: HostId is not registered

Resolution:
Most of the time simply restarting the "Forefront Identity Manage Service" and "Forefront Identity Manager Synchronization Service" from the services MMC snap-in will resolve this issue. If either of them is in a Disabled state or the problem persists after a service restart, then I recommend rebuilding the UPS from scratch as per my instructions below.


Problem:
"ILM Web Service Configuration" source logs an Event ID 234 in event logs.

ILM Certificate could not be created: Cert step 2 could not be created: C:\Program Files\Microsoft Office Servers\14.0\Tools\MakeCert.exe -pe -sr LocalMachine -ss My -a sha1 -n CN="ForefrontIdentityManager" -sky exchange -pe -in "ForefrontIdentityManager" -ir localmachine -is root

Resolution:
If you have tried to provision the "User Profile Synchronization Service" a number of times you might see this error. It occurs because there are multiple "ForefrontIdentityManager" certificates stored in the Certificate store.

Firstly you need to stop the "User Profile Synchronization Service" under Sharepoint Central Administration > System Settings > Manage Services on Server.

Then open an MMC console, add a Certificates snap-in, select Computer Account. Check the Personal, Trusted Root Certification Authorities and Trusted People stores for duplicate "ForefrontIdentityManager" certificates and delete ALL the FIM certificates.

Next under Sharepoint Central Administration > System Settings > Manage Services on Server, Start the "User Profile Synchronization Service" again, you will be prompted for the password of the Sharepoint service account it is using. It should successfully restart and create a new certificate without conflicts.


Problem:
"Microsoft Resource Management Service" source logs a Event ID 0 in event logs.

Service cannot be started. System.InvalidOperationException: Cannot find the X.509 certificate using the following search criteria: StoreName 'My', StoreLocation 'LocalMachine'

Resolution:
The "User Profile Synchronization Service" can't find a certificate when it is starting. You need to stop and then start this service. Firstly you need to stop the "User Profile Synchronization Service" under Sharepoint Central Administration > System Settings > Manage Services on Server. After waiting 5 minutes, perform an IISRESET and then press Start to restart the service. You will be prompted for the password of the Sharepoint service account it using.


Problem:
"Microsoft.ResourceManagement.ServiceHealthSource" source logs an Event ID 2 in event logs.

The Forefront Identity Manager Service could not bind to its endpoints.  This failure prevents clients from communicating with the Web services.

Resolution:
You can try restarting the "Forefront Identity Manage Service" and "Forefront Identity Manager Synchronization Service" from the services MMC snap-in. If this does not work then I recommend rebuilding the UPS from scratch as per my instructions below.


Problem:
"Forefront Identity Manager" source logs an Event ID 3 in event logs.

.Net SqlClient Data Provider: System.Data.SqlClient.SqlException: Cannot open database "DBNAME" requested by the login. The login failed.
Login failed for user 'DOMAIN\service-spsql'

Resolution:
This issue occurs if you have recreated the User Profile Service application and the database settings have not updated in the registry. It is normally a smart idea to stop the "User Profile Synchronization Service" under Sharepoint Central Administration > System Settings > Manage Services on Server, wait 5 minutes, then restart it.

If it is simply a database name wrong you can edit it in the registry under the following paths.

HKLM\system\currentcontrolset\services\FIMService

HKLM\system\currentcontrolset001\services\FIMService

HKLM\system\currentcontrolset002\services\FIMService

HKLM\system\currentcontrolset\services\FIMSynchronizationService

HKLM\system\currentcontrolset001\services\FIMSynchronizationService

HKLM\system\currentcontrolset002\services\FIMSynchronizationService

The main two values you will want to look at are "DatabaseName" and "DatabaseServer", ensure those two are correct then restart the "Forefront Identity Manage Service" and "Forefront Identity Manager Synchronization Service" from the services MMC snap-in.

If this doesn't work, then stopping the "User Profile Synchronization Service"and then restarting it from Central Administrator is your best solution.


Problem:
 "User Profile Service" source logs an Event ID 1511 in event logs. The "event user" will be one of your Sharepoint service accounts.

Windows cannot find the local profile and is logging you on with a temporary profile. Changes you make to this profile will be lost when you log off.

Resolution:
This is a fairly common problem and one of the easier ones to fix. Firstly go into your IIS management console > Application Pools and search for any application pools that have the same username as the event log user. Stop all of those application pools and then run an IISRESET.

Then from the command line run the commands. The first command adds the problem user account to the local administrator group (to aide the profile creation) and the second command creates the user profile.

net localgroup administrators DOMAIN\AppPoolAccount /add
runas /u:DOMAIN\AppPoolAccount /profile cmd

When this process is complete remove the user from the local administrators group.

net localgroup administrators DOMAIN\AppPoolAccount /delete

Then you will need to restart all the IIS Application Pools you previously stopped.


Problem:
After adding a "Synchronization Connector" to the UPS you can no longer get into "Manage User Profiles". When clicking "Manage User Profiles" the web browser simply times out with no errors in the event log or ULS logs.

Resolution:
Unfortunately I am still struggling with this one and have no resolution. On the other hand it seems to make no difference, unless you want to map custom properties, which you can do manually through the Forefront Identity Manager console from the Sharepoint server desktop. While it is annoying to not be able to access, it doesn't seem to have any functional restrictions, in my environment at least.


Recreating the User Profile Service application

1. First we need to get rid of the broken instance of UPS.

a. Under Central Administration > System Settings > Manage services on server, stop the "User Profile Service" and "User Profile Synchronization Service"

b.  Under Central Administration > Application Management > Manage service application, delete the "User Profile Service application"

c.  On the Sharepoint server itself, open an MMC console, add a Certificates snap-in, select Computer Account. Check the Personal, Trusted Root Certification Authorities and Trusted People stores for "ForefrontIdentityManager" certificates and delete ALL the FIM certificates.

d.  Open a Sharepoint 2010 Management Shell, issue the command get-spserviceapplicationpool. Remove any service application pools that are associated with previous UPS applications with the command:

remove-spserviceapplicationpool "PoolName"

e.  Delete any pending timer jobs related to the UPS synchronization service provisioning. Under Central Administration >Monitoring > Check job status, check the Running section for any related jobs and delete them.

f.  Wait 15 minutes and then issue an IISRESET before proceeding to the next step.

2. Under Central Administration > System Settings > Manage services on server, start the "User Profile Service.

3.  Under Central Administration > Application Management > Manage service application, create a new UPS. Use a different name than you did for the previous UPS instance, different database names and a different application pool name. Wait 15 minutes then issue an IISRESET.

4. Under Central Administration > System Settings > Manage services on server, start the User Profile Synchronization service. Wait 15 minutes and if both FIM services are running from an MMC services snap-in as below, issue an IISRESET.

If you get this far and have no problems opening your UPS application from Central Administration > Application Management > Manage service application then congratulations, more than likely you have resolved your problems.

You can now proceed to adding Synchronization connectors and bringing those attributes in from Active Directory.

If you are still having issues getting your UPS to work after following all these steps, then the Sharepoint MSDN forums are a great place to get help from Sharepoint gurus with much more experience than myself.