更改启用lync账户SIP地址
Can Set-CsUser construct a SIP address for you?
No, it can't. As you probably know, when you enable a user for Lync Server you can ask the system to create the user's SIP address for you. For example, this command gives Ken Myer a SIP address based on his SamAccountName:
Enable-CsUser �CIdentity "Ken Myer" �CRegistrarPool atl-cs-001.litwareinc.com �CSipAddressType SamAccountName �CSipDomain litwareinc.com
Do you have to know Ken's SamAccountName in order to run this cmdlet? Nope; Enable-CsUser will figure that out for you.
Of course, you don't have to let Lync Server create a SIP address for you; you can give someone any valid SIP address you want to give them. And, for the sake of argument, let's pretend that, while you were on vacation, another administrator enabled Ken Myer for Lync Server and gave him the SIP address sip:[email protected].
Yikes.
Note. In case you're wondering "kahuna" is a Hawaiian word that means, among other things, "an expert in any profession." So are the Lync PowerShell blog authors the big kahunas of Lync Server PowerShell?
We'd rather not answer that question.
Fortunately, SIP addresses are not written in stone; after all, you can easily change the SIP address by running the Set-CsUser cmdlet:
Set-CsUser �CIdentity "Ken Myer" �CSipAddress "sip:[email protected]"
But suppose you've decided to use a user's email address as his or her SIP address. If you were enabling Ken Myer's user account you could get Lync Server to automatically assign Ken's email address to his SIP address:
Enable-CsUser �CIdentity "Ken Myer" �CRegistrarPool atl-cs-001.litwareinc.com �CSipAddressType EmailAddress
But Set-CsUser can't do that; there's no way to auto-assign a SIP address in Lync Server once a user is enabled. That means that you're going to have to look up Ken's email address, then manually type it in when calling Set-CsUser. Which, of course, means you could mistype the address and then have to start all over again:
Set-CsUser �CIdentity "Ken Myer" �CSipAddress "sip:ekn[email protected]"
Bummer.
Now, as far as we know, there's no way to somehow coerce Set-CsUser into auto-assigning a SIP address for you. But there is a nifty little trick we stumbled upon while playing around with this. Before we show you that trick, let's recap: Ken Myer has already been enabled for Lync Server; as it turns out, he's also been enabled for Enterprise Voice, been assigned a line URI, and been assigned a bunch of policies. In other words:
Identity : CN=kenmyer,OU=Redmond,DC=Litwareinc,DC=com
VoicePolicy : RedmondVoicePolicy
ConferencingPolicy :
PresencePolicy :
DialPlan : RedmondDialPlan
LocationPolicy :
ClientPolicy : ITDepartmentPolicy
ClientVersionPolicy :
ArchivingPolicy :
PinPolicy : ITDepartmentPinUser
ExternalAccessPolicy : FederationAndPICDefault
HostedVoiceMail :
HostedVoicemailPolicy :
HostingProvider : SRV:
RegistrarPool : atl-cs-litwareinc.com.com
Enabled : True
SipAddress : sip:[email protected]
LineURI : TEL:+114255551111;ext=1219
EnterpriseVoiceEnabled : True
With that in mind, we wondered what would happen if we simply re-enabled Ken's account for Lync Server:
Enable-CsUser �CIdentity "Ken Myer" �CRegistrarPool atl-cs-001.litwareinc.com �CSipAddressType EmailAddress
To be honest, we sort of expected that re-enabling his account would wipe out all of his previous policies and settings. But, much to our surprise, that's not what happened:
Identity : CN=kenmyer,OU=Redmond,DC=Litwareinc,DC=com
VoicePolicy : RedmondVoicePolicy
ConferencingPolicy :
PresencePolicy :
DialPlan : RedmondDialPlan
LocationPolicy :
ClientPolicy : ITDepartmentPolicy
ClientVersionPolicy :
ArchivingPolicy :
PinPolicy : ITDepartmentPinUser
ExternalAccessPolicy : FederationAndPICDefault
HostedVoiceMail :
HostedVoicemailPolicy :
HostingProvider : SRV:
RegistrarPool : atl-cs-litwareinc.com.com
Enabled : True
SipAddress : sip:[email protected]
LineURI : TEL:+114255551111;ext=1219
EnterpriseVoiceEnabled : True
The only thing that changed was his SIP address, which was automatically set to his email address. Nothing else changed; for example, all the policies that had been assigned to him remained assigned to him.
To be honest, we had no idea that would actually work.
So is that an absolutely perfect solution? No, not necessarily. For one thing, we haven't put this through an exhaustive and comprehensive set of tests; that's something you might want to do before trying on a real user and a real user account. For another, you still have to type in the correct Registrar pool. If you only have one Registrar pool that should be no problem. If you have multiple Registrar pools, you might have to be a bit more careful: you could potentially create some problems by assigning Ken to the wrong pool. Still, we thought it was a cool little trick, and something you might be interested in trying sometime.