Tuesday, 12 March 2019

Online Archive missing in Outlook after Office ProPlus upgrade

We recently upgraded a bunch of users from Office 2013 / 2016 Professional Plus to Office 2016 ProPlus using our O365 E3 licences. A bunch of users, both on-prem and in O365, could no longer see their Online Archive in their Outlook. The online archive was gone, kaput, missing, absent, you get the idea.

Interestingly, it did show up in their Outlook Online / on-prem webmail however.

This pinpointed it to probably being their Office 2016 KMS licence key from the previous install. A check of the current licences a user had looked like:

"c:\windows\system32\cscript.exe "C:\Program Files (x86)\Microsoft Office\Office16\ospp.vbs" /dstatus"
PRODUCT ID: xxxxx-xxxxx-xxxxx-xxxxx
SKU ID: d450596f-894d-49e0-966a-fd39ed4c4c64
LICENSE NAME: Office 16, Office16ProPlusVL_KMS_Client edition
REMAINING GRACE: 178 days  (257459 minute(s) before expiring)
Last 5 characters of installed product key: abcde
Activation Type Configuration: ALL
        KMS machine name from DNS: x.x.x.x:1688
        Activation Interval: 120 minutes
        Renewal Interval: 10080 minutes
        KMS host caching: Enabled
Hmmm, an old licence in there. Not sure why it would cause issues, but it's not the one they should have for O365. So, delete the licences with this command, using the last 5 characters of installed product key from the above command:
"c:\windows\system32\cscript.exe "C:\Program Files (x86)\Microsoft Office\Office16\ospp.vbs" /unpkey:abcde"
Restart Outlook and provided the user has a proper E3 / E5 licence, Online Archive should be visible.

Tuesday, 7 August 2018

Errors reinstalling MS Advanced Threat Analytics

When our MS ATA server was set up, we had to choose a certificate to use for the encrypted communications between domain controllers and the ATA server. So we picked the default computer cert issued by our internal PKI which was valid for another year.

What we forgot was this certificate expires and self renews. This error would have been recoverable had it been noticed before the server was rebooted, but it wasn't. So because the old cert was gone, we couldn't start the ATA services and the domain controllers were no longer talking to the ATA server. We rebuilt the ATA server and tried to reinstall the agents on the DC's. Perhaps there is an easier way....

This is where the problems started on our server-core DC's. Sometimes the agent would uninstall and sometimes not. It wouldn't upgrade however.

So, in order of things I tried to remove the agent:

With the new agent install executable in the current directory, try
Microsoft ATA Gateway Setup.exe /quiet /uninstall
If that didn't work, start a PowerShell and use the WMI:
$app = Get-WmiObject -Class Win32_Product -Filter "Name = 'Microsoft Advanced Threat Analytics Gateway'"

If it's still installed, there are some log files (Microsoft Advanced Threat Analytics Gateway_yyyymmddtime.log)for each installation attempt of the agent in your %temp% (or one directory up like C:\Users\al\AppData\Local\Temp) that make for some reading like:

[0410:0C24][2018-08-07T14:10:58]i000: 2018-08-07 02:10:58.6626 1040 5   Debug [\[]DeploymentModel[\]] [\[]DeploymentAction=Upgrade[\]]
[0410:0C24][2018-08-07T14:10:59]i000: 2018-08-07 02:10:59.1313 1040 5   Error [\[]GatewayBootstrapperApplication[\]] Failed to create deployment manager [\[]exception=System.ArgumentNullException: Value cannot be null.
Parameter name: path1
   at System.IO.Path.Combine(String path1, String path2)
   at Microsoft.Tri.Gateway.Deployment.Bundle.UI.Application.GatewayUpgradeDeploymentConfiguration.GetMandatoryConfiguration(String installationPath)
   at Microsoft.Tri.Gateway.Deployment.Bundle.UI.Application.GatewayUpgradeDeploymentConfiguration..ctor(Engine engine, String installationPath)
   at Microsoft.Tri.Gateway.Deployment.Bundle.UI.Application.GatewayDeploymentModel.CreateDeploymentConfiguration(Engine engine)
   at Microsoft.Tri.Deployment.Bundle.UI.Application.DeploymentModel..ctor(BootstrapperApplication bootstrapperApplication, ProductComponent productComponent, String productFullShortName, String productFullLongName, String productFullLongDisplayName)
   at Microsoft.Tri.Gateway.Deployment.Bundle.UI.Application.GatewayDeploymentModel..ctor(BootstrapperApplication bootstrapperApplication)
   at Microsoft.Tri.Gateway.Deployment.Bundle.UI.Application.GatewayBootstrapperApplication.CreateDeploymentModel()
   at Microsoft.Tri.Deployment.Bundle.UI.Application.BootstrapperApplication`1.Run()[\]]

This one was fixed by going to "C:\ProgramData\Package Cache" and searching for *.exe (dir *.exe /s). You'll see some GUID's and file names like "Microsoft ATA Gateway Setup.exe" then run the uninstall command with the path including the GUID
"C:\ProgramData\Package Cache\{GUID}\Microsoft ATA Gateway Setup.exe /uninstall"
Repeat for each version of that EXE you find under that directory. That should do it.

Finally, go and delete the contents of "C:\Program Files\Microsoft Advanced Threat Analytics\Gateway" then remove the directories "Gateway" and "Microsoft Advanced Threat Analytics" otherwise you get errors in that log like:

[13BC:1244][2018-08-07T14:15:33]i000: 2018-08-07 02:15:33.5655 5052 5   Debug [\[]DeploymentModel[\]] [\[]DeploymentAction=Install[\]]
[13BC:1244][2018-08-07T14:15:33]i000: 2018-08-07 02:15:33.8155 5052 5   Debug [\[]DeploymentModel[\]] [\[]IsAfterRestartAndConfigured=False[\]]
[13BC:1244][2018-08-07T14:15:37]i000: 2018-08-07 02:15:37.1749 5052 5   Error [\[]DeploymentManager[\]] InstallationPath is invalid [\[]directoryState=NotEmpty[\]]
[13BC:1244][2018-08-07T14:15:37]i000: 2018-08-07 02:15:37.1905 5052 5   Debug [\[]GatewayBootstrapperApplication[\]] Engine.Quit [\[]deploymentResultStatus=1602 isRestartRequired=False[\]]

You are then free to reinstall the agent with:
"Microsoft ATA Gateway Setup.exe" /quiet NetFrameworkCommandLineArguments="/q"

Thursday, 22 February 2018

Error 2150858882 with Event Log Fowarding

After setting up a GPO for the event log forwarding service to use https instead of http to talk to our collector, with the recommended settings of server, refresh and issuerCA, I kept getting this 105 error in the Eventlog-FowardingPlugin log on my workstations:

The forwarder is having a problem communicating with subscription manager at address https://mycollector.alsheppard.com:5986/wsman/SubscriptionManager/WEC.  Error code is 2150858882 and Error Message is .
That's it, no error message. Frustrating. However, removing the IssuerCA, leaving the server and refresh values from the GPO's SubscriptionManager line seems to have resulted in a happy event forwarding service.

I would also check Kerberos is set up on the listening server, or at least the SPN exists.

Thursday, 13 November 2014

Voice mail in Outlook 2013 won't Play on Phone

We have users who are trialling Office 365 for their email but use an on-premise Lync 2013 phone system. When they get a voice mail in their Outlook 2013 (with and without SP1), there is a Play on Phone option that is meant to ring their phone and play the voice mail.
However, when they click on that, the following error pops up.
The Microsoft Exchange Unified Messaging service cannot be contacted to play messages on your phone. Try again later. If this problem continues, contact your Exchange administrator or support organisation.
Being that I administer our Exchange 2010, I got lumped with finding out why it wasn't working. It took a while to check certificates etc between Lync servers, the UM servers, CAS boxes and the O365 end points and they all looked fine. There was no error messages in any server logs either.

Interestingly, if I did the same "Play on phone" action from the Office 365 Outlook Web interface it worked meaning that at least from off site, the certificates were fine and everything was talking. After another look at the client with Wireshark, I noticed that there was no network traffic when you click the button which lead me to looking at the Outlook client. Testing a few hotfixes later and it seems that KB2880477 is the answer.

There is no mention of the issue in that KB but the version of the Outlook 2013 SP1 add-in "Microsoft Exchange Add-in"'s  UmOutlookAddin.dll changed from 15.0.4569.1503 to 15.0.4629.1000 and the Play on Phone now works.

Wednesday, 23 July 2014

Changing the Federation Service name in ADFS 3.0

I was configuring a Windows Server 2012 R2 server with ADFS to talk to Office 365 and set it up with the wrong name (fs.alsheppard.com) instead of the desired sts.alsheppard.com. Easy I thought, I'll just go and change it in the ADFS config and test it. Nope, that didn't work. Ok, I'll Google it. Nope, NOTHING about changing the Federation Service name in ADFS 3.0 (as at March 2014).

So, how I fixed it (in my mythical alsheppard.com domain).

  • In the AD FS mmc tool, on the right is the "Edit Federation Service Properties" and change the FS name and identifier.
  • Add the new DNS name sts.alsheppard.com to point to the same IP address as the fs.alsheppard.com
  • Update the certificate that it uses. Powershell and run "Update-ADFSCertificate". This will generate the new token-decrypting certificate and token-signing certificate that you can see in the MMC (under AD FS -> Service -> Certificates). The fs.alsheppard.com certificate is still the primary.
  • In the gui, notice that you can't change the primary and secondary around yet. In the powershell, run "set-ADFSProperties -AutoCertificateRollover $false".
  • In the gui again, change the new sts.alsheppard.com to be the primary and delete the old fs.alsheppard.com certificates in both sections.
  • In powershell, run "set-ADFSProperties -AutoCertificateRollover $true"
  • In ADUC, change the SPN value on the ADFS farm service account from "host/fs.alsheppard.com" to "host/sts.alsheppard.com"
  • In the Powershell again, type "get-ADFSSslCertificate" and this should show three certificates, two for the fs.alsheppard.com hostname and one for localhost. Copy the CertificateHash and use it here "set-ADFSSslCertificate -thumbprint <CertificateHash>. Run the get-ADFSslCertificate again and there should be 5 certificates now, one for localhost, two for the old name and two for the new name. This must be done on each server in the farm.
  • In the mmc, change the Device Registration Service identifier too (AD FS -> Trust Relationships -> Relying Party Trusts).
  • Restart the ADFS service.
That should be about it. Test it by going to "https://sts.alsheppard.com/adfs/ls/idpinitiatedsignon" and seeing if you can log in. If not, check that the ADFS farm service account has read rights to the user account you are trying.

In hindsight, deleting the farm, wiping the farm server and restarting from scratch would have been about as easy.

Edited  20150908 to change the set-ADFSProperties certificate rollover, thanks anonymous commenter!