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:
    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.

For some users in OWA the SFB meeting button is not working

I recently worked on an issue that was somewhat confusing. The Skype for Business button was missing for some users. Not all users just some.

We were not able to narrow this down to just one user, one site or even one pool. It made for a fun time trying to troubleshoot where the issue was occurring. IM and presence were working just fine in OWA too!!

So what did we find? So we started troubleshooting this one as you would any other case with the OWA button. We verified OAuth (even though it worked for some users). We ran and verified the Test-Csexchangeconnectivity this all came back clean for the user. We ruled out the machine by logging in elsewhere, inside and outside the org. We collected Fiddler traces. This opened up a jumping point for us to troubleshoot.

The working user we could see the line “IsUcwaSupported”:true as seen below. In a non-working user replace true with false.

Searching on Lyncdiscover also showed us the following:

{“SipUri”:””,”IsUcwaSupported”:false,”DiagnosticInfo”:”AnonymousAutodiscover_Exception_NoInnerException_Both http and https anonymous autodiscover requests failed with errors (‘’, ‘’)”}

Finally something to use in logging. I then setup CLSlogging and captured on UCWA and WebInfra. Searching on my user(s)  I was surprised to learn that in a non-working scenario there were no hits for the user. However, for the working user we were able to find the following when I put the output into snooper:

As you can see after searching on the AutoD from the CLS logs from a working user  I can see the flow of the request. What we are looking for here is the response back from Autod (Exchange)  “Authorization: Bearer XXXX.” Then we see the various 200’s and we are authenticated. IF you do not see this more than likely you are also getting the above error about AnonymousAutodiscover.

In a non working this would not show as we are not able to capture logging from a Skype perspective.

At this point we need OWA logs from Exchange:

After working with the OWA team more so just to see if we could resolve we found that for the same user was only able to resolve the url on a few servers. We found that the servers that we could not resolve were on different subnets versus the ones we could resolve. As we dug further into this we discovered that this appeared to be an Express Route/Firewall issue.

While we were using Express Route to cover all the Subnets for 0365 this appeared to affect the way the Oauth path/token worked. For the subnets that we had added outside the Express Route this worked perfectly. So we reached out to the Firewall team. After some discussions we pulled out the way the subnets were setup and entered them in outside the Express Route. After we did this we were able to create Skype For Business Meetings inside OWA.


Mac Delegation for SFB On Prem

SFB Mac delegation On-Premises


Recently  I have worked on a few cases where the delegation for MAC is not working as expected. There are a few things that need to be verified before this option is available in the On-Prem environment.


  • Both the Boss (Delegator) and Admin (Delegate) must be enterprise enabled
  • The delegate (admin) must be homed in the same forest as the delegator (Boss) user account
  • EnableDelegation must be true for the CsVoicePolicy
  • EnableDelegateManagement must be true for CsPlatformServiceSettings update: this is on by default in the Dec 2017 CU found here
  • Please note this was introduced here
  • UcsAllowed must be false for CsUserServicesPolicy (Lync Server 2013 only)

So let’s walk through this:


I will use Test3 as the boss and test4 as the admin


So we verified our users are EV enabled:



I only have one domain so the forest portion is easily verified.


In my voice policy we see that the Enable delegation is set to true:


Now since I have applied the CU needed for CSPlatformservicesettings I see by default this is set to false:


‘Set-CsPlatformServiceSettings –EnableDelegateManagement $true’




Since this is a 2015 pool the UCSAllowed does not apply here


So now over to our Boss on the Mac client:

  1. On the Contacts tab, search for the contact you want to add as a delegate.
  2. Right-click the contact to show the available contact options. (Or click the person’s photo to show the contact card.)
  3. Select the Groups icon and then select My Delegates.

Now we can sign in as the admin and we should see we were added as the delegate for Test3 (Boss)


At this point we are all done and you should be able to use the delegation as expected with the Mac client with SFB on Prem.