Master & Cmd-R

Troubleshooting ADFS/CBA: Error 342

I ran into this error today while configuring Certificate Based Authentication (CBA), and it was a weird enough of an issue that I thought it would be useful to post it, and share the fix.

After configuring my CRL so that it was published publicly (this is required for both your Root CA, as well as your Enterprise CA), and installing my certificates on both my ADFS servers and WAP servers (again, both the Root CA certificate and the Enterprise CA certificate are required), CBA was still failing when trying to log in to the Office 365 Portal.

Well, we’re no stranger to error logs and troubleshooting, right? Off we go to the ADFS logs to see what’s going on.

The Error: Event ID 342

This error basically states that it couldn’t build the trust chain for the certificate, usually because it can’t properly access your CRL all the way up the line.


I knew this wasn’t the case, because I had already tested that using one of my issued certificates – the command to do this is:

certutil -f -urlfetch -verify certname.cer

(replace certname.cer with the name of your cert)

This command will go through and check all of the URLs listed on the cert and verify connectivity to them – it’s great for checking your CRL/CDP/AIA distribution points and making sure that they’re all accessible internally and externally.

Next, I checked all my certificates on the local computer certificate store to verify that I didn’t have any old certificates, duplicates with wrong information, etc. – everything was as it was supposed to be. I eventually found an answer indirectly on this forum post – it didn’t list my issue exactly, or provide the fix I used, but it DID provide me with the tools I needed to figure it out.

The Fix: clear out old certificates

It turns out that the issue was being caused by old certificates sitting in the NTAuth store on my ADFS servers – it’s bizarre, because I had deleted all my old certificates and replaced them with new ones containing updated CRL distribution points, etc. However, that did not clear them out of this certificate store, as these certificates are being pulled directly from Active Directory.

Here’s how you check for these little deviants, and how to get ’em all fixed up:

Start by running the following command:

certutil -viewstore -user -enterprise NTAuth

(like so)


This will pop up a view of your NTAuth certificate store: scroll through the list of certificates until you find the one relating to your Enterprise CA:


Now, you can see that the certificate is definitely still valid (not expired) – however, I know that I updated my CRL & AIA locations and the new certificate that I’ve installed on all my servers is valid from today’s date, not August 2017.

Next, open the certificate properties by clicking on the link below the date, and note the thumbprint of the certificate:


Next, open the registry, and match that certificate thumbprint against the certificates found in HKLM\Software\Microsoft\EnterpriseCertificates\NTAuth\Certificates.


Then I simply deleted the registry key that matched that thumbprint (always make a backup of your reg key before you delete it!). This time when I run checked my NTAuth store by running the command above, that Enterprise CA certificate was completely gone.

Finally, to update the NTAuth store and pull in a new certificate, I ran the following command:

certutil -pulse


Now when I check my NTAuth store, I can see that it’s pulled in the correct certificate:


You can, of course, verify this by opening the certificate and making sure that the thumbprint matches your current certificate, and that the correct CRL & AIA distribution points are listed. Once this was done, my trust chains were able to build correctly, and certificate based authentication immediately started working. 😀

There you have it… if your struggling to get CBA configured, and you know you’ve updated all your certs with the correct CDP, give this a shot and see if it solves your problem!

Office ProPlus: Access to Group Files

This is something that we’ve been waiting to see since April 2017, but I’m so happy to see it’s actually there now!

I looked around and couldn’t find this change listed on the Office 365 Roadmap, or even on the Office Insider sites – kudos to Michiel van den Broek on the Microsoft Tech Community for calling it out.

Dude, where’s my files?

Ever since Teams was announced, I’ve been hoping for better integration between Office and Teams – especially around opening and saving your documents within your Team Sites. The navigation was always clunky, and looked pretty much like this:


Prior to this change, trying to navigate your Teams document repositories that weren’t either pinned or part of your recent documents meant that you’d have to try and navigate through the SharePoint sites, like this:


Needless to say, the only way that made sense was navigating to the files in Teams, and then opening them in Word, or Excel, or maybe doing the same thing through SharePoint. The reverse of that would be to save a new file somewhere local, and then copy it over/upload it to your Team.

New and Shiny!

After installing the latest Office Insiders build (Version 1712 – Build 8827.2131 Click to Run), I was greeted by the following:


TADA!! I can easily navigate all my Groups and Teams from within Office Applications!

Clicking on Open when Recent is selected still looks the same:


But if you click on Sites again, you can navigate your Teams sites with ease!


I know it’ll take a while before these changes get out of the Insiders Track and into general availability, but if you want to get early access to these and whatever other cool features are coming down the line, you can sign up to be an Office Insider here.

Error Opening Office 365 Meeting Requests

Ran into this issue recently, and it’s a bit of a weird one that you might possibly run into as you’re migrating to Office 365.

Here’s the scenario:

A cloud user sends a meeting invite to someone on prem – on prem user accepts the invitation, and everything’s all good (so far). Cloud user updates the meeting invitation and attaches a document, and sends the meeting update out. All of a sudden, the on prem user can no longer open the meeting, or access the attached document. The error only seems to happen between users who were already migrated when they were sending the meeting invite back to on prem users – sending meeting invites back and forth between cloud users wouldn’t reproduce any issues; on prem users could send back and forth just fine also without issues.

First thought of course, was that there was something messed up in the sharing settings as the invite crosses orgs, or possibly something broken in hybrid – wouldn’t be the first time some weird firewall rules caused issues in hybrid, right?

However, it wasn’t a hybrid issue at all, it was something even weirder – the cloud to on prem side of the scenario was actually a red herring… that’s the only way it was happening, but the issue is actually caused because all the migrated users had also been upgraded to Office Pro Plus (2016), and the on prem users were still on Office 2013!

The issue: HTML Calendaring

Turns out there’s a known issue that can happen with meeting requests that are created in Outlook 2016 and then opened in Outlook 2013. According to the support article, the error has to do with the way Outlook 2016 formats calendar requests, particularly meeting requests that have “table content, embedded images, and attachments”.

I tried to reproduce the issue in my own environment, and here’s what I found…

Starts with a regular calendar invite – everything works fine:


Then I went back and added a document, table, and image to the meeting request (might as well do them all, right?)and sent out the update:


Sure enough, opening the attachment in Outlook 2013, the HTML options (image, table, attachments) are either messed up, or missing, or corrupted. If the message appears corrupted, the recipient won’t be able to open it at all.


In my case, I was still able to open the meeting request and the attachment, but the content was definitely messed up.

Interestingly enough, the content looks fine in OWA:


The Fix:

Option 1: Upgrade to Office ProPlus

If you have the ability to upgrade your users to Office ProPlus, this is by far your best option – your users will be using the latest and greatest, and won’t run into issues like this again.

Option 2: Update Office + Registry Settings

According to the support bulletin, you need to install KB3127975, and then add these registry settings:

  1. Open your registry, and navigate to Computer\HK_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\Options\Calendar, right click, and choose New – DWORD (32-bit) Value:


  1. Name the key AllowHTMLCalendarContent, and then edit it and change the value to 1:


Exit the Registry editor, and restart Outlook, and you should be good to go.

I’d still suggest upgrading to Office Pro Plus if you have the licensing to support it – in the meantime, however, this will at least make sure that your users are not having issues opening HTML meeting requests. Hope it helps!

PowerShell: Connect to Lync Online

The issue: unable to discover PowerShell endpoint URI

I don’t run into this error very often, but it’s happened enough times in the last few weeks that I really wanted to come up with a permanent/elegant solution. This error can happen when Lync/Skype is configured in a hybrid deployment, and autodiscover is pointing back on-prem – when trying to connect to Lync Online using the New-CSOnlineSession cmdlet, you receive the following error:


The Fix: Override Admin Domain

The solution is simple – all you need to do is add the -OverrideAdminDomain switch to your connection script. You can add the admin domain permanently to your script, and be done with it. For me, however, I often end up connecting to multiple environments depending on the projects I’m working on, or supporting different clients, etc. I wanted a more elegant solution, so I came up with a way of automating that process so that I can connect to any environment just by putting in my logon credentials. The script will check and find the onmicrosoft domain, and then use that to connect to a new CSOnline session with that domain specified as the admin domain.

This is what the script looks like:

$credential = Get-Credential
Connect-MsolService -Credential $credential

# Find the root (onmicrosoft.com) tenant domain
Write-Host "Connected to MS Online Services, checking admin domain..." -ForegroundColor Yellow
$msolDomain = Get-MsolDomain | where {$_.Name -match "onmicrosoft.com" -and $_.Name -notmatch "mail.onmicrosoft.com"}

Write-Host "Admin domain found, connecting to $($msolDomain.Name)" -ForegroundColor Green

# Use this domain to connect to SFB Admin domain
$session = New-CsOnlineSession -Credential $credential -OverrideAdminDomain $msolDomain.Name
Import-PSSession $session

And there you go… connected properly, every time!


Feel free to download the script, and add it to your toolkit – hope it helps!

Error Re-configuring ADFS

I recently had to re-deploy an ADFS farm, and ran into the following error while finishing the ADFS configuration:

Unable to open the physical file: “C:\Windows\WID\Data\AdfsArtifactStore.mdf”. Operating system error 2: “2(The system cannot find the file specified.)”


Not only is the error a bit misleading, it also doesn’t give you any ideas on how to fix it – searching around on the web didn’t turn much up around that error (of course it didn’t), so I ran through the basic troubleshooting steps:

  • Checked to verify that I have the right permissions / admin access: Check
  • Reboot: Check

I was going to go down the route of downloading the SQL management tools, connecting to my WID and digging around to see if I could figure out what was broken – before I got to that, though, I figured I’d try resetting the WID and seeing if that resolved the problem. Thankfully, this turned out to be a simple solution, and only took a few minutes to complete.

NB: The only way I found to reset the WID was to uninstall / reinstall it – not a problem if this is a new server you’re configuring, or if you plan to overwrite the configuration anyway. Just don’t do this if you’re co-locating any other services that might be using the WID. You shouldn’t be, but still… this option DELETES THE WID ENTIRELY!

With that warning out of the way, let’s get to it:

  1. Open Server Manager, click Manage, then Remove Roles and Features:


  2. Uncheck the Windows Internal Database, and click Next:


  3. Confirm your uninstalling the WID, and click Remove:


  4. Finally, open Windows Explorer and go to C:\Windows\WID\Data – select all the files in this folder, and delete them:


** Remember I told you that you’re deleting your WID – don’t go through with this if you’ve got something else running on this server that might be using it! **

Go ahead and reboot the server and then go back into Server Manager, and this time choose Add Roles and Features, click through the starting selection pages, check the box beside the Windows Internal Database, click Next, then Install.

Once you’ve completed the install, go back and re-run your ADFS config, and Bob should most definitely be your Uncle:


(Since this is a secondary server being added to an existing farm, this warning is expected – all good!!)

Office 2013 and Modern Auth

I’ve been working on a project recently where we’ve been running into some weird issues with Modern Authentication in general, and MFA specifically. It basically boils down to needing to understand two things:

  1. Office 2010 does not like Modern Auth at all; and,
  2. Office 2013 only really likes Modern Auth conditionally.

Now, I know what you’re thinking… duh! We already knew that Office 2010 doesn’t support modern auth, and so if you have MFA enabled on your account, you won’t be able to use Outlook 2010. Well, here’s where things get a bit trippy…

This environment had ADFS configured for Single Sign On, and so MFA is configured to skip multi-factor authentication for requests from federated users on my intranet, like so:


However, we were finding that users with MFA enabled were still unable to configure their Outlook profiles, and instead would just get constantly prompted for username and password, and the profile would never fully configure.

It turns out that even if you have MFA excluded for your internal networks, as long as MFA is enabled on a user account, Office 365 will require a modern auth request before it even gets to the place of determining whether or not MFA is required. If you’re using Outlook 2010, the only way to get passed this is to use an app password. Now, app passwords are not the end of the world, however, when you’re looking at using Outlook and Skype together, your users will need to log in to Skype using their AD credentials, but whenever Skype pops up asking for Outlook integration, this needs to be your app password.

Very. Confusing.

So what does this mean for Office 2013? We know that it’s supposed to support modern auth, as long as you have the proper registry keys set up on the workstation. These two keys are required:

[HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\Identity]

“Version”=dword:00000001

“EnableADAL”=dword:00000001

Along with this one to make sure that Outlook is using OAuth (Modern Auth) for Autodiscover:

[HKEY_CURRENT_USER\Software\Microsoft\Exchange]

“AlwaysUseMSOAuthForAutodiscover”=dword:00000001

More info on these reg keys here:

https://support.office.com/en-us/article/Enable-Modern-Authentication-for-Office-2013-on-Windows-devices-7dc1c01a-090f-4971-9677-f1b192d6c910

However, even with those reg keys applied, we were still having an inconsistent experience in Outlook 2013 for accounts with MFA enabled. Sometimes everything would configure and work properly, and sometimes it’d just prompt for username and password constantly until the account locked out – this would invariably happen because Lync or Skype would be prompting for Outlook credentials, and wouldn’t accept username and password.

It wasn’t until I started looking at the Office 2013 version that I began to see the problem – the Office 2013 clients that were having issues with modern auth were not fully patched up to the required levels. The functionality to enable modern auth in Office 2013 didn’t come out until the March 2015 Update Release: https://blogs.technet.microsoft.com/office_sustained_engineering/2015/03/10/march-2015-office-update-release/

So I did some testing, and here’s what I found…

A fresh install of Office 2013 SP1 gives you version 15.0.4569.1506 in Add/Remove Programs. However, the installed version listed in the Control Panel only gives you the base version, and it doesn’t show you what your update level is at.


The only way to find this info is to go into an Office program, click File, then Account, then About Word/Outlook etc. You can see here that the base install of Office 2013 SP1 gives you .1504 with an MSO of 1506. The MSO number is the one you want to watch out for, as that’ll tell you the latest patch number installed.


Testing the base install of Office 2013, all you get is a basic auth prompt – even though the reg keys have been applied. In essence, Outlook 2013 is acting the same as 2010 in this regard – basic auth only.


Fully Patched (as of October 2017):


You can see the difference immediately when you try to configure an Outlook profile – prior to being patched, Outlook would send a basic auth request which wouldn’t work. Once you have your patches and reg keys in place, Outlook pops up a modern auth prompt:


And then MFA works as expected (or doesn’t show up at all if you have internal networks excluded).


I found it took several rounds of updates before Office 2013 was fully patched – the first round of updates took me right before the March update that I needed (15.0.4701.1002):


After second round of updates:


This is close enough if you just want to get Modern Auth working properly – I always like to see Office and Windows fully patched… who knows what else has gotten fixed along the way that might come around and bite you next? Patch!

After the final round of updates:


And finally… good to go!


So the moral of the story is this – when in doubt, make sure that you’re up to date! Don’t just assume that WSUS has been doing its job, or users haven’t been ignoring their updates for years – more often than not, there’s gaps that can cause weird issues like this to crop up.

Hope this helps!

Resize Azure Managed Disk

I recently was trying to resize the OS Disk of an Azure VM that I had just created, and ran into an error while using these instructions. In case you missed it, make sure you stop/deallocate your VM before trying to update the disk – otherwise it’ll just fail on you.

For the record, this is what the PowerShell looked like that I was trying to use:

$rgName = ‘My-Resource-Group’
$vmName = ‘My-VM’
$vm.StorageProfile.osDisk.DiskSizeGB = 1023

Update-AzureRmVM -ResourceGroupName $rgName -VM $vm

No dice! 🙁

Update AzureRmVM: Managed disk size via virtual machine ‘My-VM’ is not allowed. Please resize disk resource at /pathtomanageddisk/diskname.

Error code: ResizeDiskError

Now, the reason for this is that I had created this new VM using managed disks, and you can’t update those directly using the Update-AzureRmVM command. It took a little bit of digging to figure out how to update that managed disk, so I figured I’d post how I’d done it, in the hopes that it’ll help someone else out.

Since it’s a managed disk, running Get-AzureRmStorageAccount will not show you your disk – instead, you need to run Get-AzureRmDisk.

You can see that my disk size is 127GB, and not the glorious Terabyte I’m hoping to see:

Now that you’ve found your disk, go ahead and grab the name of your disk (or pull it into a variable if you prefer) and then simply update the size of the disk with the following command:

New-AzureRmDiskUpdateConfig -DiskSizeGB 1023 | Update-AzureRmDisk -ResourceGroupName $rgName -DiskName MyVM_OsDisk_1_crazylongnumbers

Verify that your disk looks correct by running

Get-AzureRmDisk -DiskName MyVM_OSDisk_1_crazylongnumbers

Next, Start your VM back up using the following command:

Start-AzureRmVM -ResourceGroupName $rgName -Name $vmName

(or use the Azure portal if you prefer, but c’mon… PowerShell!!)

Once back in your VM, you can see that your disk size is unchanged – this is because Windows knows about the newly available space, but doesn’t auto-expand your disk drive.

Right click on the start menu, and select Disk Management. You can see your disk now has unallocated space to match what you specified in PowerShell:

Go ahead and select the disk and extend it to fill the usable space, and you’re good to go!

Hope this helps – if this helped you, or you have any questions, feel free to shoot me a comment below.

Limit OneDrive Access from Non-managed Devices

Microsoft has recently released conditional access policies in Azure AD Premium / Intune that will allow you to restrict access to SharePoint and OneDrive from non-managed devices. While this feature is still in preview (expected to go GA by the end of the year), I believe it’ll go a long way to helping companies properly control access to potentially confidential data without needing to block access to OneDrive entirely.

Conditional Access Requirements
In order to use Conditional Access features, you require subscriptions in Azure AD Premium and Intune, and First Release needs to be enabled for everyone in your organization – this setting is found in the Office 365 Admin Portal under Settings – Organization Profile on your tenant (will require up to 24 hours for the feature set to be enabled once you switch):

Enabling Conditional Access Policies
These policies can either be configured in the Azure portal under the conditional access blade in Azure AD or Intune.

Configure a SharePoint Browser Restriction Policy
Start by selecting Conditional access, then Policies, and click New policy:

Give the policy a name, and start working through the options blade – first up is the user assignment; either assign the policy to all users, or select the users or groups you want it to apply to:

Next, choose the Cloud apps blade, and select Office 365 SharePoint Online:

Note that you can set both inclusions and exclusions here – so far I’ve only tried including SharePoint Online, as this is what we’re configuring specifically.

Under the Conditions blade, select Client apps, then choose Configure: Yes, and select Browser under client apps:

Since this policy specifically only targets browser access, that’s the only option we want to select here – we’ll need to create a second policy to restrict access to mobile app and desktop clients.

Access controls is set to Grant access without restrictions, but you can see that you can further lock things down on this tab:

The final option to configure is under the Session controls – check the box to Use app enforced restrictions (preview):

Enable the policy if you’re ready to go, and then click Save.

Configure a SharePoint Device Restriction Policy
Next, we’ll need to enable a device restriction policy in order to prevent users from simply getting around these restrictions by using the mobile apps or sync client.

Just like before, click on New policy, and give it a unique name. The first few settings are exactly the same:

  1. Under users and groups apply to all users (or restrict it to test users as before);
  2. Under Cloud apps, select Office 365 SharePoint Online;
  3. Under Conditions – Client apps, select Mobile apps and desktop clients:

  4. The final option to select is the conditions under which access will be granted. If you plan to use several options like I have below, make sure you pay careful attention to whether or not you require ALL or ONE of the selected controls, depending on how restrictive you’d like to be.

Obviously, you’ll want to set this based on your own requirements, but I think having a device either be domain joined, or Intune compliant is a good way to go. This allows you to support a mixture of managed device types – mobile phones for instance, can’t be domain joined, so you’ll need to allow for them to be managed / compliant instead of just domain joined. One caveat to this specific restriction is that devices need to be registered in Intune in order for them to be properly detected as compliant. If a mobile device is not registered in Intune, then access to the SharePoint / OneDrive app will be blocked, as it will neither be compliant or domain joined.

SharePoint Configuration
Once these policies have been created (and First Release enabled on the tenant), the following options can be configured in the SharePoint admin center, under Device Access:

The first option is the two policies we just enabled in Azure AD Premium, and option two actually sets the SharePoint restrictions that we’re looking for.

It’s also important to note that enabling this configuration blocks applications that don’t use modern authentication. I’m still trying to find out what kind of impact this has on Office 2010, but I don’t expect there should be much concern, as Office 2010 doesn’t integrate with SharePoint Online the way Office 2013 and 2016 do.

End User Experience
Once these policies have been applied, users will see the following banner when accessing a SharePoint or OneDrive document library, as well as when access OneNote notebooks in SharePoint Online:

The banner is not displayed while navigating through regular SharePoint sites, it only appears when accessing document libraries, or OneNote notebooks (which are stored in document libraries).

Also, the SharePoint and OneDrive libraries no longer have the New Document, Download or Sync options, and these options also disappear from the document context menu:

Opening up an Office document displays the same banner as above:

The documents are also read only while this is enabled – you don’t have the option to edit the doc, and you can’t copy paste out of this document into another one.

All in all, this is a solid option for locking down access to SharePoint and OneDrive resources, without needing to completely block OneDrive for Business. Users can still have full functionality on trusted machines, but very limited access across the board while on personal or untrusted devices.

Exchange Online Hybrid: Fixing free/busy issues

Now, I’m just going to come out and say it – this is NOT the only fix for free/busy issues when configuring Exchange Online Hybrid with an on-prem Exchange server. If you’re reading this, then it’s more than likely that you (like me), have been reading countless TechNet articles, blog posts, forum posts, etc. Well, at the end of it all, this was the fix for my free/busy issues, and I thought others might benefit by finding this ahead of time, and hopefully cut out some of the Googling Binging… 😉

The Problem:

Pretty straightforward – users on prem could not see the free/busy status of users in Office 365. I worked my way through every setting I could think of, including (but not limited to) Autodiscover, DNS, permissions, certificate settings, Exchange CU level, to no avail!

Also, if you haven’t seen this before, the hybrid environment free/busy troubleshooter was actually a great help in systematically working your way through potential problem spots.

The Solution:

Eventually, I came across this TechNet blog post which gave me the answer I needed – now, I will say that I’ve never had to set this before, and never noticed this setting missing on previous hybrid configs, but anyway…

In my on-prem environment, the TargetSharingEpr setting was blank, like so:

Thankfully, the fix for this is simple – run the following from an elevated PowerShell prompt:

Get-OrganizationRelationship | Set-OrganizationRelationship -TargetSharingEpr https://outlook.office365.com/ews/Exchange.asmx

This is what it should look like when you’re done:

I also checked my Exchange Online org settings and found that the TargetSharingEpr was also blank:

Now, I wasn’t having any issues with free/busy in this direction, but I thought I’d go ahead and update it anyway – just in case. Make sure that this time around, you’re connecting to Exchange Online, and not your on-prem Exchange, and point it back to your EWS endpoint:

Get-OrganizationRelationship | Set-OrganizationRelationship -TargetSharingEpr https://hybrid.mydomain.com/ews/exchange.asmx

(I don’t have to tell you that hybrid.mydomain.com needs to be updated to your own hybrid namespace, do I?) 😛

When you’re done, it should look like this:

There you have it – hope this helps someone else solve some free/busy issues without having to spend hours of frustrating trying everything else!

Oops! Access to Azure Active Directory is not available

When trying to access the Azure AD admin portal from within Office 365 recently, I ran into the following error:

Now, this shouldn’t be an actual problem, as Office 365 is built on the Azure AD identity platform, and clicking on the link to the admin portal should just work properly – but then *should* is a funny word, isn’t it?

One of the suggestions I found on the web was to go to https://manage.windowsazure.com, and sign up for a trial subscription:

Well, don’t do this: (it’s not necessary!)

See, the problem comes from the fact that the Azure AD link in Office 365 still goes to the old Azure portal (manage.windowsazure.com, and account.azure.com).

Instead of going through all that mess, and signing up for an Azure trial you don’t need, simply navigate to https://portal.azure.com, and click on Azure Active Directory: (ignore this error about your dashboard not found, it doesn’t matter)

As you can see, all is right with the world!


Update: All fixed!

Microsoft has now fixed this problem, and the link to Azure AD from the Office 365 portal now properly resolves to a new portal: https://aad.portal.azure.com… Shiny!!