Category Archives: O365

Skype4b Online SIPAddress/UPN Mismatch

A recent troubleshoot case for which I did not have enough alcohol for to deal with.  A client was enabled in Office 365 for Skype Online, but had issues with Signing into the Skype client.  Checked all the usual suspects like DNS, licensing, PEBCAK, all without success.  Everything in the Portal looked correct.

PowerShell time:
Import-Module SkypeOnlineConnector
$credential = Get-Credential
$session = New-CsOnlineSession -Credential $credential
Import-PSSession $session -AllowClobber

Get-CsOnlineUser -Identity “Bob Smith” | fl *voice*,*PSTN*,*lineuri*,ObjectID,*SIP*,UserPrincipalName

In my output, the the SipAddress and the SipProxyAddress was a combination of the users ObjectID and UserPrinciplaName.  Armed with this new information, the user was able to use the combined SIP address as the Sign in Address, then use his UPN name for the User Name, and then the password.  It worked, but not acceptable.

Unfortunately we are provided with few tools to affect changes.  I am more accustomed to On Premises deployments where I can play god, but in Skype Online, I just feel more like Perseus or Hercules, some god-like powers, but outside looking in and a little bitter…

Set-CsUser is very limited in the Skype Online PowerShell, and you definitely can not modify the SIP Address, as per Article ID: 2909916.  So, very frustrating.

Technically, the SIP address is supposed to be populated with the User Principal Name (UPN), but in some odd cases, this does not happen.  After trying way to many ways to list to correct this, the “only” way currently (April 4, 2017, it’s O365, things change monthly) is to change the users UPN attribute via PowerShell.  You can try Option A and see if it works.  This particular case required Option B, much more extreme and time consuming.

Option A)
1) Start Windows PowerShell
2) run: Install-Module -Name MSOnline
3) after installation is complete, run: Connect-MsolService and enter credentials.
4) Run: Get-MsolUser -UserPrincipalName “bob.smith@company.com” | fl to confirm successful connection.
5) To change the UPN: Set-MsolUserPrincipalName -UserPrincipalName “bob.smith@company.com” -NewUserPrincipalName “bob.smith@company.onmicrosoft.com”

Now wait and O365 Minute (15-60 minutes), and observe that the users Account changes in the Portal.  Their Sign in address as well as their default SMTP address change.  Using your SkypeOnline powershell, recheck the SIP address.

Option A is actually very similar to a Online user name change, where you would set the UPN to their new name in essence, and once changes have completed, you would just stop there.  In this situation, we want to change back to bob.smith@company.com, and assuming the above process worked,  run the following command and wait another O365 Minute:

6) Run: Set-MsolUserPrincipalName -UserPrincipalName “bob.smith@company.onmicrosoft.com” -NewUserPrincipalName “bob.smith@company.com”

Bob wasn’t so lucky in his case.

Option B)
1)  Make note of the user’s current UPN, and any other Skype properties like LineURI, ect:  Get-CsOnlineUser -Identity bob.smith@company.com | fl *voice*, *PSTN*, *lineuri*, ObjectID, *SIP*, UserPrincipalName
2) Skype Online disable the user by removing all Skype licensing including but not limited to: Skype for Business Cloud PBX, Skype for Business PSTN Conferencing, Skype for Business Online, Skype for Business PSTN Consumption
3) Wait a O365 minute for the users Skype properties to fall off
4) Follow steps 1-5 in Option A using PowerShell to modify the UPN and wait the O365 Minute.  Additionally check the Users Exchange email address properties.  Here you can also see the incorrect SIP address prior to changing the UPN. It should disappear and the EUM address should also change.  IF the default SMTP address has changed to the new UPN, but the EUM has not, manually change it by just removing the ObjectID from the address, and then remove the bad SIP address.
5) Run step 6 of Option A, wait the O365 Minute for the Primary email address and user name to change back.  Check the Email Addresses again, see that the EUM has also changed to the correct UPN/email address and not the ObjectID
6) Re-enable the Skype Licensing that you previously disabled, and wait for Skype Online Provisioning to take place again for the user.  (O365 minute)

Assuming everything went well, the SIP Address should end up populating with the UPN address once again.  Verify the Email Address properties, PS or Portal, see that EUM and SIP are correctly populated.

Site wide validation couldn’t hurt right, try this Skype Online PS command:

get-csonlineuser | where {$_.SipAddress -ne “sip:”+ $_.userprincipalname} | fl DisplayName,UserPrincipalName,Sip*

Oh, and no explanation as to why this might happen, though the internal thinking is it’s DirSync related, BUT this client never had a Domain let alone DirSync.

 

 

LS Storage Service 32054, A New Twist

Stop me if you’ve heard this one before…  “A guy walks into a bar, and says ‘Ouch'”.  Also, a Skype administrator reviews the Frontend Event logs and sees LS Storage Service errors, event id 32054, and says ‘ignore’.  Guess what, not today!!!

Log Name:      Lync Server
Source:        LS Storage Service
Date:          12/19/2016 9:32:45 AM
Event ID:      32054
Task Category: (4006)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      SFB2015.Company.net
Description:
Storage Service had an EWS Autodiscovery failure.

StoreWebException: code=ErrorEwsAutodiscover, reason=GetUserSettings failed, smtpAddress=Bob@Company.com, Autodiscover Uri=https://autodiscover.Company.com/autodiscover/autodiscover.svc, Autodiscover WebProxy=<NULL>, WebExceptionStatus=ConnectFailure —> System.Net.WebException: Unable to connect to the remote server —> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 40.96.38.248:443

Our environment is a common one now I think, a combination of Exchange Online with Skype for Business On Premises.  And unlike the people who are Both Online, or Both OnPrem, our Skype for Business Mobile client doesn’t get to enjoy server side Conversation History.  The key reason, OAuth.  I’ve gone through the Microsoft process of configuring Onprem with Online, and it’s ugly, MSLink and honestly couldn’t tell if it did anything and it certainly didn’t get my Server-Side Conversation History working for mobile devices.  Fortunately a hero comes along, in this case Aaron Marks, who developed a script to make that step soooo much easier and quicker.  Configure-OAuth.  There are a couple of items you need to install on a Frontend, MS Online Service Sign-in Assistant and AAD PowerShell Download Link.  The key to this script that I keep forgetting, it MUST be run via the Azure Active Directory (AAD) PowerShell (elevated of course).  I keep trying with Skype PowerShell and fails miserably.  You must also be Global Admin on the O365 portal, Exchange and Skype Admin only is not sufficient.  Typical command:

Configure-OAuth_ExOn_Sfb_Server.ps1 -WebExt “webext.company.com”

Works extremely well, but still no conversation history for mobile.

This weekend I completed a pool-to-pool transition and I’m reviewing the logs, damn 32054.  Complaining about the Autodiscover again.  I’m thinking maybe the ExchangeAutodiscoverUrl line of csOAuthConfiguration is maybe supposed to be changed to autodiscover.outlook.com or something equally ridiculous. (damn, still can’t spell rediculus without autocorrect).  Next hero walks in, this time Adam Hand and he nonchalantly mentions to set the ExchangeAutodiscoverUrl with HTTP instead of HTTPS.  I don’t know where he got the divine inspiration for that gem, but a few expletives were emitted on my part.  Maybe all you super Skype Admins knew this, if so, you’re jerks.  :p  MS support certainly didn’t when I had a running conversation for 3 months about this exact scenario not working.

Summery: When Skype Onprem is deployed with Skype Online, the set-csOAuthConfiguration command would be as follows:

Set-CsOAuthConfiguration -Identity Global -ExchangeAutodiscoverUrl http://autodiscover.company.com/autodiscover/autodiscover.svc

Note the HTTP not HTTPS.  Also if you’re checking from you are just getting the URL from your CAS server, change the .xml to .svc.

Within about 5 minutes you should start to see some new entries in your event logs as follows.  Of course this is all assuming you have Autodiscover properly set up in the first place.  The SCRAMBLE’s I added just in case someone got some funny ideas…

And Test-CsExStorageConnectivity now works too.

Log Name:      Lync Server
Source:        LS Storage Service
Date:          12/19/2016 10:22:37 AM
Event ID:      32046
Task Category: (4006)
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      SFB2015.Company.net
Description:
A properly configured certificate from the OAuth Token Issuer was found.

#CTX#{ctx:{traceId:184SCRAMBLE9420, activityId:”be6SCRAMBLE-adc”}}#CTX#
Found OAuthTokenIssuer Certificate, serialNumber=44SCRAMBLE00035, issuerName=CN=IRC-DC02, DC=Company, DC=net, thumbprint=6DESCRAMBLECE20
Log Name:      Lync Server
Source:        LS Storage Service
Date:          12/19/2016 10:22:37 AM
Event ID:      32048
Task Category: (4006)
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      SFB2015.Company.net
Description:
OAuth was properly configured for Storage Service.

#CTX#{ctx:{traceId:184SCRAMBLE9420, activityId:”be6085f9-SCRAMBLE-f6df8f77badc”}}#CTX#
CsOAuthConfiguration validly configured
Log Name:      Lync Server
Source:        LS Storage Service
Date:          12/19/2016 10:22:37 AM
Event ID:      32052
Task Category: (4006)
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      SFB2015.Company.net
Description:
OAuth STS was properly configured for Storage Service.

#CTX#{ctx:{traceId:184SCRAMBLE9420, activityId:”be6085f9-SCRAMBLE-f6df8f77badc”}}#CTX#
GetAppToken succeeded for request with sts=https://accounts.accesscontrol.windows.net/f5e8862b-SCRAMBLE-b67b33a9001a/tokens/OAuth/2

Log Name:      Lync Server
Source:        LS Storage Web Service
Date:          12/19/2016 10:26:15 AM
Event ID:      32001
Task Category: (1307)
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      SFB2015.Company.net
Description:
Storage Web Service has been loaded.
Log Name:      Lync Server
Source:        LS Storage Web Service
Date:          12/19/2016 10:26:24 AM
Event ID:      32006
Task Category: (1307)
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      SFB2015.Company.net
Description:
Storage Web Service request succeeded.

 

UPDATE Dec 27, 2016:  Well, apparently these event errors don’t disappear with the change, BUT, it does resolve the OAuth issue and I do get to have Server Side conversation history working with the Skype for Business Mobile client for a Skype OnPrem/Exchange Online environment.

Thou shall not let Internal Users connect to External Edge Interface…

Been involved with UC for a while, long before it was called UC, and over time we’ve all developed cardinal rules when it comes to deployments.  One that me, and I know several others have adhered to “Thou shall not let Internal Users connect to External Edge Interface”.  Right!?!

Times are a changing, and rules are often made to be broken, add the one above to the list, or bending of it anyway.  Extended Skype Online/Hybrid coexistence.  While in a Hybrid configuration users Online and Users Onprem are one big happy environment, right?  Wrong!!  Reality is, they are two separate environments with a Shared SIP Namespace, with some bits of Replication from Onprem to Online thrown in.  (Online doesn’t replicate to OnPrem, see other postings).

Usually this is all good, UNTIL, an Online user who normally works from home decided to come into the Office one day.  They sign in no problem, they hit up SIP and the Internal sees they’re an Online user, redirects the up, and right as rain.  Time to join the Onprem meeting hosted by their in office Manager.  Audio/Video works, but nooo presentation, and a error message comes up when trying to share content to Present:  “Your DNS configuration is preventing you from presenting content” or possibly other variants.

Skype Online users when signed in are for connectivity purposes, are External Federated Users, and actually need to connect to the Web Conferencing Interface on the External Edge.   If you’ve been following the aforementioned cardinal rule, there is not likely a name resolution for WebConf, and/or possibly firewall rules blocking internal connection to the External interface.

Don’t believe me, it’s in TechNet as a requirement for Hybrid: https://technet.microsoft.com/en-us/library/jj205403.aspx

webconf

Another odd scenario, and I hope this is rare; One large International Corporation, Separate forests, separate Domains, but replicating their split-brain internal DNS zones which house the internal SIP/Skype DNS entries.  Corporate Site A can’t resolve webconf.corporateB.com, because they have B’s internal Split-Brain Public zone replicated/resolved, instead of the Public DNS Zone.

Seems like the new rule now is, Add the External Web Services and Webconf FQDN’s to your Internal split brain DNS zones now.

Good times.

Additional note:  The Skype Online AV traffic also appeared to be going through the Edge AV NIC in the Wireshark captures.  Same machine signed into an Onprem account, connected directly with the Frontend.

Skype for Business Hybrid pt.1

I’m sure there will be many more parts to this as O365 is ever “evolving”, euphemism for “it’s bloody different every time I go in there…”

An issue I recently hit when trying to connect an OnPrem Skype environment to a company’s Online counterpart, aka setting up Skype4b Hybrid, I ran into this lovely error:

Get-CsWebTicket : Failed to connect live id servers.  Make sure proxy is enabled or machine has network connection to live id servers

s4bhybrid

After verifying and re-verifying numerous items like: connectivity; access portal to verify password; review every powershell command; DNS entries; confirm moving csusers via PowerShell; and moon phases, it was time to contact support.  A week later, plus 2-4 engineers (who can keep track), I get the knowledgeable one.

Run these 3 commands, from an As Administrator CMD prompt, not PowerShell:

ICACLS %windir%\System32\config\systemprofile\AppData\Local /grant *S-1-5-20:(OI)(CI)(RA)

ICACLS %windir%\System32\config\systemprofile\AppData\Local\Microsoft\MSOIdentityCRL /grant *S-1-5-20:(OI)(CI)(IO)(F)

%windir%\system32\inetsrv\appcmd recycle apppool /apppool.name:LyncIntManagement

Good to go after that, no more problems signing in, and was able to complete the “Set up Hybrid with Skype Online” wizard, plus move users up and down without the use of Skype PowerShell.

This is potentially an issue with CU-259, not sure when it began or when it will be fixed, but the above commands appear to apply a missing/broken ACL.

Special shout out to Arran on his article for Online-to-Onprem setups.  His section on getting the already Online users enabled in the newly created Onprem system, saved my bacon:  https://blog.kloud.com.au/2015/08/26/skype-for-business-online-to-on-premises-migration/

Additional note for Skype Hybrid setups, when creating the new CSHostingProvider, check your Skype Online Admin Panel.  IF the URL is admin1a.online.lync.com, your Autodiscover URL on your hosting provider will likely change to https://webdir1a.online.lync.com/Autodiscover/AutodiscoverService.svc/root after you’ve completed the “Set up Hybrid with Skype Online” wizard.  At least that’s my experience every time.  Doesn’t matter much, just being petty I’m sure, but next time I’ll be trying this command out instead, assuming its admin1a again.

New-CSHostingProvider -Identity SkypeforBusinessOnline -ProxyFqdn “sipfed.online.lync.com” -Enabled $true -EnabledSharedAddressSpace $true -HostsOCSUsers $true -VerificationLevel UseSourceVerification -IsLocal $false -AutodiscoverUrl https://webdir1a.online.lync.com/Autodiscover/AutodiscoverService.svc/root