Skype For Business contact migration to Teams

Every now and then when migrating Skype users to Microsoft Teams the contacts will not migrate over. Here is a quick blog on what is required and limitations of what can be migrated over.

Requirements for SFB to Teams:

  • Users cannot be UCS enabled, The users contacts must be stored on SFB and NOT Unified contact store or UCS.
  • Obviously the users account must be online
  • Users need to be in Teams only for the contacts to be migrated

Limitations:

  • Only Federated and Tenant contacts will be migrated
  • Maximum number of contacts is 1000
  • Max number of groups is 64
  • Skype consumer contacts do not get migrated
  • Any distribution groups also will not get migrated

How the migration process works:

  1. The contacts will be triggered to migrate once the user clicks on the contacts tab in Teams. While this will trigger the migration the users will not see the contacts until the migration is complete and they have logged out and back in.
  2. If the migration fails it will re-trigger after 8 hours.
  3. If users are not enabled for federation the federated contacts will not migrate
  4. If users are UCS enabled then the contacts will not migrate. Once UCS is set to false and the contacts have moved over to SFB the process will re-trigger

UCS cmdlets can be found here:
https://docs.microsoft.com/en-us/skypeforbusiness/deploy/integrate-with-exchange-server/use-the-unified-contact-store

Set-CsUserServicesPolicy -Identity global -UcsAllowed $False

Rollback the UCS policy by using Invoke-CsUcsRollback -Identity “user” if you do not roll back the user from UCS the contacts will not be removed for the contact store. If you do not change the policy and you run the rollback after 7 days the contacts will revert back to UCS.

DEBUGGING TOOLS INSTALL ERROR (VISUAL C++ 2015 X64 MINIMUM RUNTIME – 14.0.23026)

Are you trying to install the Skype for Business debugging tools or the Reskit? Are you getting the below error message?

To fix this simply run the following cmdlet:

msiexec /a c:\software\SkypeForBusinessDebugTools.msi /qb TARGETDIR=C:\yourpathhere

You will have to change the above cmdlet to match what you are trying to do and where you are trying to extract it to. Once this is done you should now be able to run the debugging tools or the Reskit.   

Office Web Apps Server

Recently worked an issue with Office Web Apps Server aka OWA or even WAC server. The issue simply was it would not work.

There is not to much to these things. Couple of configuration settings and you are pretty much good to go.

So I checked the basics:

verify you can reach the discovery url from the browser
Collect client logs and server logs
Server components are as followed:

Component: DataMCU
=> Level: Verbose
=> Flags: All
Component: DataMCURunTime
=> Level: Verbose
=> Flags: TF_COMPONENT,TF_PROTOCOL,TF_NETWORK
Component: DataProxy
=> Level: Verbose
=> Flags: All
Component: GraphListener
=> Level: Verbose
=> Flags: All
Component: GraphService
=> Level: Verbose
=> Flags: All
Component: Infrastructure
=> Level: Verbose
=> Flags: All
Component: InternalCommon
=> Level: Verbose
=> Flags: All
Component: LDM
=> Level: Verbose
=> Flags: All
Component: WebInfrastructure
=> Level: Verbose
=> Flags: All

Also have fiddler running while reproducing the issue.

So, once I collected all the logs its obviously time to review. Client logs were showing the following:

<diagHeader>54031;reason=”The WAC presentation failed with a server error.”; There is a few other lines like the url for the OWA server etc.

So Fiddler captures the error and we look at the url its trying to use. There I noticed that the url that was being created was pointing outside my network. I then checked my topology for the Office Web App and where it thinks the server location is:

Well this is not correct. My WAC server is internal. I then proceeded to change the topology and set my Office Web Apps servers location to internal and then published the topology. Once this was done testing proved that it is now working.

Hopefully this will help anyone that is having that “odd: issue.

 

 

Deleting corrupt UM call answering rules

  • The call answering rules are also known as ‘Personal Auto Attendants’ (PAA). They are stored as a binary property in a message of type ‘IPM.Configuration.UM.E14.PersonalAutoAttendants’ in the mailbox root’s associated contents table. Here are instructions (with screen shots) to find it:
  • https://github.com/stephenegriffin/mfcmapi/releases/tag/18.2.18213.260
    1. Using MFCMapi, logon to the affected mailbox
      1. Launch MFCMapi
      2. From the main window, choose ‘Session->Logon…’ from the menu
  • If asked, choose a profile
    1. Note: In my instance, the profile was set to online only – I was not caching the mailbox contents locally

Open the ‘Microsoft Exchange Message Store’ entry by double-clicking it

The mailbox window should open, showing the un-expanded ‘Root Container’

Right-click the ‘Root Container’ and choose ‘Open associated contents table’

In the ‘Display Name Not found (Hidden Contents)’ window, move over to the ‘Message Class’ field

Find the message labelled ‘IPM.Configuration.UM.E14.PersonalAutoAttendants’ Right click on this message and choose ‘Delete Message’

In the ‘Delete Item’ dialog box, you have three options under ‘Deletion Style’

In my lab, I chose the ‘Permanent delete passing DELETE_HARD_DELETE (unrecoverable)’ because I wanted to make sure the commandlets were unable to find the message in my deleted items or similar. The other options MAY WORK, if you want to experiment with them.

PLEASE NOTE: THIS RESULTS IN DATA _LOSS_; all personal UM call answering rules will be IRRETRIEVABLY LOST; please test thoroughly and vette the procedure extensively.

Once you’ve deleted the item, you can close MFCMapi and attempt the UMCallAnsweringRules; they should now work.