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.
Enable-CsUser “user” –RegistrarPool “pool fqdn” –SIPAddressType EmailAddress –PassThru | Set-CsUser –EnterpriseVoiceEnabled $true
The Enable-CsUser does not have a EnterpriseVoiceEnabled parameter which you can set to $true. You can always break the commands into two and avoid using the –PassThru parameter as well.
This piece of info will come in handy if you are scripting the Lync administration – maybe in a migration or new Lync deployment.
I came across a deployment in which the work number was the default option while selecting the “Call” option in the Lync client.
How to change it so that the default is always a Lync call? Pretty straightforward – All that is needed is a change to the client policy. Run the command below in the Lync Shell.
Set-CsClientPolicy “Policy Name” –EnableVOIPCallDefault $true
Once the change is made, the default option is always the Lync call.
If you have custom client policies defined, say a site level or user level one, make sure that the change is made on the policy that gets applied to the end user.
I have been meaning to write for other websites for quite some time, but never got around to doing it.
Things have changed as I am able to put some more time into writing and I have started with SearchExchange website, managed by the TechTarget Group.
Two of my articles are online.
First one goes into detail about all the arbitration mailboxes in Exchange 2013 and ways to recover them.
Second one is about Discovery, Monitoring and Public Folder Mailboxes in Exchange 2013.
As always, comments are welcome.
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.
Any other workaround guys?
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).
I came across this error message while uninstalling an Exchange 2010 server.
Setup cannot continue with the uninstall because the cscript process has open files. Close the process and restart setup.
The issue was that the System Center Management service was locking the files.
After stopping the System Center Management service, the readiness check passed and I was able to uninstall Exchange properly.
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?