I came across a user not being able to sign in to the Lync 2010 client when Lync 2010 server was deployed in a resource forest.

The user was getting the normal error message.

Cannot sign in to Lync. You may have entered your sign-in address, user name, or password incorrectly. If your sign-in information is correct and the problem persists, please contact your system administrator.

Since the error message pointed to login credentials, I verified the following.

I reset the user password to be sure.

Account was not locked out.

I could sign in from the user machine, which confirms that it is not a machine issue.

The problem was that a required attribute was not set for the user. When Lync 2010 is deployed in a resource forest along with Exchange, the MSRTCSIP-OriginatorSID attribute should match the msExchMasterAccountSid. In this user’s case, the attribute was not set (blank).

Once I set the attribute using ADSIEdit, the user was able to sign in straightaway.

A question that came via email from an AD admin was about ways to package an MSI file for Lync 2010 client installation via group policy.

It is a common practice to deploy software using group policies and Lync is no exception. But, when you have a look at the downloaded Lync 2010 client, it is an exe and not an msi file. So, how do we go about packaging the Lync client?

Fortunately, Microsoft does provide an MSI, but not in a straightforward fashion. install the Lync 2010 client on a machine and the MSI file is created as part of the install in C:\Program Files (x86)\OCSetup folder. There it is!

Use this msi file to push the Lync 2010 client using group policy. One hurdle that you need to overcome is the fact that msi install of Lync client is not allowed by default. A registry edit takes care of this problem. Read KB2477965 for the fix.

Enabling a user for Lync and enterprise voice is easy, if you know how the Enable-CsUser cmdlet works.

You can always enable a user for Lync and enterprise voice in one go from the Lync control panel. You can assign all the policies as well from the GUI.

If you want to enable a user for Lync from the shell, the cmdlet we need to use is Enable-CsUser. In order to find user(s), the cmdlet is Get-CsUser.

The Get-CsUser cmdlet gives us most of the info regarding a user – like the SIP address, pool fqdn, whether the user is enabled for enterprise voice, various policies etc.

Hence, you would think that you can use the Enable-CsUser to enable a user for Lync and enterprise voice using the same cmdlet. Wrong! You need to use the Enable-CsUser and Set-Csuser. The reason for this is that the Enable-CsUser cmdlet doesn’t pass objects through the pipeline by default. You need to use the –PassThru paramter and pipe the output to the Set-CsUser cmdlet.

For example, to enable a user for Lync and EV, the command is as follows.

What are the different ways to join a Lync online meeting with Chrome set as the default browser?

You want the Lync 2010 thick client to be “the client” for everything including joining online meetings. But when Chrome is set as the default browser, it comes up with a webpage asking us to join the meeting using the browser or to download the Lync Attendee. If IE is your default browser, there is no issue.

One workaround is to use the IE Tab extension from the chrome web store.

Once the extension is active, you can join the meeting as you would when you have IE as the default browser. You can of course copy and paste the meeting url into an IE browser and join the meeting that way.

Many a times you have to find the version of the various components installed on your Lync server. What are the different ways to figure it out?

There is no native one-liner Lync Shell cmdlet to find this information. The easiest option will be to go to Programs & Features (in the control panel) and you will have a list of all Lync components and their versions.

A third way is to use the Lync Server Update Installer that comes with each CU. Run the installer and it will show you all the components on the server and the installed version. You can patch the server using the same tool.

Yet another option is to run Get-CsManagementStoreReplicationStatus from the Lync Shell.

There are few more ways to find the base version of the product. But, are there any other ways to find the version of the components?

I came across this error message regarding the number of concurrent shells being exceeded while using EMC 2010.

Connecting to the remote server failed with the following error message. The WS-Management service cannot process the request. This user is allowed a maximum of 18 concurrent shells, which has been exceeded. Close existing shells or raise the quota for this user.

The above error message is self explanatory. The user in question has more than 18 concurrent shell connections to the Exchange server, probably in a number of remote sessions to various servers.

The limit is imposed by the throttling policy in Exchange. In my case, the default policy has the maximum PowerShell concurrency set to 18.

How to fix this issue?

Close any unused/unwanted shell connections

Edit the throttling policy for the user and raise the limit to a higher value, say 25. Run Set-ThrottlingPolicy Default* –PowerShellMaxConcurrency 25 to set it. If you have a number of throttling policy, you need to find the one that is applied to that user and edit it.

You can also create a new policy with higher limits and apply it to the user (maybe for all admins).

The new Office 365 (Wave 15) brings in a lot of new features and a nice one is the automation work in verifying the domain and setting up DNS records.

The initial Office 365 offering gave steps on how to verify a domain and create the necessary DNS records. There were instructions specific to few companies like GoDaddy and a general one for all other hosting providers.

The Wave 15 Office 365 has made the process much easier. My domain is registered with GoDaddy and while adding the domain, Office 365 picks it up and makes verifying easier by just clicking the Confirm Ownership button.

A new window will be opened where I had to sign in with my GoDaddy credentials. That’s it and the domain was verified. No more setting up of TXT records and waiting for replication.

The creation of the necessary DNS records have been automated fully. You are asked as to what features you need – from Exchange, Lync and SharePoint online. I selected the first two and clicked the Setup Records button.

And voila, all the necessary DNS records were created.

Now that saves a lot of time and effort in getting the values right manually – to setup both Lync & Exchange services externally.

I checked the GoDaddy portal and sure enough they were all created.

Just double checked I am assuming that Office 365 will automate the process for all major hosting providers. Has anyone used a provider other than GoDaddy and seen the automation?