User is not validly homed on target

At a new deployment I saw an issue when some users were enabled for Lync, they could not sign in.

When we investigated the client certificates, I saw this error:

Disable and re-enable the user did not change anything.

Luckily we also had a Survivable Branch Appliance (SBA) in the deployment, so forcely moving the user to the SBA, did change something, so the user was able to login. Hey now things work, but having the user at the SBA was not what we wanted, so we moved the user back to main pool and we were back at the beginning... The user could not sign in. 

Luckily we had also a test user with this problem, so production users would work and we could do more investigation for this problem.

I escalated the problem to Microsoft PSS, who is working on it now... Hopefully this post will be updated soon.

Update: The problem was caused by some incorrect routing group IDs, the problem was identified by event id 30057 in the Lync Server eventlog, text is:
msRTCSIP-UserRoutingGroupId attribute for a user is incorrect in Active Directory domain:<AD-domain>
The user with these attributes has DN:<USER-DN>
These incorrect attribute cannot be updated in the database.
Source of replication is: LocalRegistrarReplication.
Resolution:
This is usually caused due to home pool information change in Active Directory using unsupported tools or direct edits to AD. To resolve this condition, move all the affected user back to the original Pool using Move-CsUser and then move the user again to this Pool gracefully using Move-CsUser.

Neither moving the user (who btw originated on this very pool), removing the content of MSRTCSIP-UserRoutingGroupID field of the object nor a full reset of the pool did resolve this issue. So we decided to renew the local databases.

First backup userdata (just in case):
Export-CsUserData -PoolFQDN <fqdn> -FileName <filename>

Then on all FEs:
Stop-CsWindowsServices
Install-CsDatabase -LocalDatabases -Clean
Restart-Server

After all the servers are back online the error was gone.

The problem was also causing some response groups to stay in offline mode with event id 30058 in the Lync Server eventlog, this was also solved with this action.

Forwarding hunt group calls to a group voicemail

During a deployment, we were met with the request of calls in a hunt group (or queue) should be able to go to an Exchange UM enabled mailbox for the department/function.

HG name is department@sipdomain e.g. test@kml.local
Exchange mailbox is department@sipdomain e.g. test@kml.local
UPN for the Exchange mailbox is the same as the e-mailaddress

The mailbox account is (should be) disabled in AD, so first move is to enable the account. Then I enable the account for Lync using Powershell:
Get-CsAdUser -Identity "test@kml.local"|Enable-CsUser -RegistrarPool Lyncpool.kml.local -SipDomain kml.local -SipAddress sip:vm.test@kml.local

The Lync user should be Enterprise Voice enabled to be able to utilize the UM mailbox
Set-CsUser -Identity test@kml.local -EnterpriseVoiceEnabled $True

Next step is UM enabling the mailbox (implies that a UM Mailbox Policy has already been defined) this could be done using the Exchange Control Panel or Powershell:
Enable-UMMailbox -Identity "test@kml.local" -UMMailboxPolicy UmPolicy1 -Extensions 2000 -PIN 13579 -SIPResourceIdentifier "test@kml.local"

Now we'll use SEFAUtil to set the Lync forwarding destination for test@kml.local.
.\SEFAUtil.exe /server:lyncpool.kml.local test@kml.local /enablefwdimmediate /setfwddestination:"sip:test@kml.local;app=voicemail"

Now we can assign the Forward to Voicemail destination in the HG setup and don't forget to record a greeting in the Exchange mailbox.

After recording a greeting, you should consider disabling the AD account again. If you decide to disable the account, the users of the mailbox cannot record a new greeting unless an administrator (you) reenable the account again.