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
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:
Open Server Manager, click Manage, then Remove Roles and Features:
Uncheck the Windows Internal Database, and click Next:
Confirm your uninstalling the WID, and click Remove:
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!!)
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:
Office 2010 does not like Modern Auth at all; and,
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.
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:
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.
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.
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:
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:
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:
Under users and groups apply to all users (or restrict it to test users as before);
Under Cloud apps, select Office 365 SharePoint Online;
Under Conditions – Client apps, select Mobile apps and desktop clients:
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.
Ran into the following error while attempting to offboard a mailbox (migrate it back on prem from Exchange Online):
MigrationPermanentException: Cannot find a recipient that has mailbox GUID ‘xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx’
This error is usually caused when a mailbox is created directly in the cloud (New – Office 365 Mailbox in Exchange console on prem). The Exchange mailbox GUID doesn’t actually get written back on-prem in this case, so trying to offboard a user results in this error. You can confirm this by connecting to your Exchange Shell on premises and do a Get-RemoteMailbox username | FL ExchangeGUID.
To fix this problem, connect to Exchange Online and find the GUID that’s missing:
Then simply take that GUID and write it back to your on prem remote mailbox object:
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… 😉
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!
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:
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:
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?
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!!
Scott Duffey has put together some excellent articles (four parts in total) around setting up Azure AD based CBA, and deploying certificates to mobile devices. It’s worked really well as a guideline for me in setting up certificate based authentication in production environments – however, there’s one scenario that isn’t covered in these articles, and if you’re running a two-tier PKI architecture, you’re going to have some headaches.
Part 2 of the series discusses how to configure your Azure AD as a Certification Authority, but it only shows you how to add your root CA as your trusted certificate authority. If you have a Root CA and an Enterprise or Intermediate CA, you need to upload both certificates into Azure AD. Without this step, your CBA won’t work because your certificate trust chains won’t properly build out. Also, make sure that you publish all required CRLs – if you have a Root CA as well as an Intermediate or Enterprise CA, make sure that both CRLs are publicly available, as you’re going to be setting those URLs using the PowerShell script below.
# Install Root CA (AuthorityType=0). CRL Distribution Point should be the CRL of the Root CA $rootcert=Get-Content -Encoding byte “C:\users\username\Desktop\AzureCA\RootCA.cer” $new_rootca=New-Object -TypeName Microsoft.Open.AzureAD.Model.CertificateAuthorityInformation $new_rootca.AuthorityType=0 $new_rootca.TrustedCertificate=$rootcert $new_rootca.crlDistributionPoint=“http://domain.com/crl/RootCA.crl” New-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $new_rootca
# Install Enterprise CA (AuthorityType=1). CRL Distribution Point should be the CRL of the Enterprise CA $entcert=Get-Content -Encoding byte “C:\users\username\Desktop\AzureCA\EntCA.cer” $new_entca=New-Object -TypeName Microsoft.Open.AzureAD.Model.CertificateAuthorityInformation $new_entca.AuthorityType=1 $new_entca.TrustedCertificate=$entcert $new_entca.crlDistributionPoint=“http://domain.com/crl/cmdrEntCA.crl” $new_entca.DeltaCrlDistributionPoint=“http://domain.com/crl/EntCA+.crl” New-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $new_entca
# Remove existing Certification Authority –  for first cert,  for second, etc. $c=Get-AzureADTrustedCertificateAuthority Remove-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $c
The important key above is using the AuthorityType=0 for your Root CA, and AuthorityType=1 for your Enterprise CA. I also added a section that will allow you to clear out your certificates and start over if you need to – just use  to remove your first cert, and  to remove your second.
I’ve been using this script to streamline my connection to the Exchange Online Shell, and it’s been working well for me – until recently when I ran into this weird “Access Denied” error:
As you can imagine, I started out by troubleshooting issues with my account, trying to figure out why I was being denied access, including stuff like what this article talks about (bad username/password, not being an Exchange Online admin).
I knew however, that this was not my issue – I confirmed my password, and my account was a global admin in Office 365. Turns out, the issue was caused not by any specific access being denied on my user account, but more specifically because I was connecting to an Exchange Online tenant that was configured for Multi Factor Authentication! If you’re getting the access denied error connecting through the old way, it’s time for a bit of a change.
There are two ways to resolve this issue, depending on how you want to use your scripts – I use the connection script above quite frequently in my other scripts to connect to Exchange Online, and so I wanted to be able to keep using it.
Fix 1: Use an account that is not enabled for MFA
The first fix is more of a workaround than a fix – simply use a global admin account (or an account with the Exchange Admin role) that is not enabled for multi-factor authentication. This is a good place to set up a cloud only admin account, and connect using firstname.lastname@example.org, or simply use an on-prem account with MFA disabled – either/or.
Connect using MFA:
If instead you want to start connecting to the Exchange Online shell using MFA and Modern Auth, you’ll need to install the Exchange Online Remote PowerShell Module, and follow the instructions here.
You know you’re using the right module, because it has a blue Exchange icon, and it also gives you this information in yellow text when it loads.
Like it says, you initiate a connection by using Connect-EXOPSSession, like so:
You can see that you’re greeted by a Modern Auth prompt instead of your typical basic auth prompt:
Which then passes on to your MFA approval flow:
For the record, if you’re still getting this credential prompt:
You’re still using basic auth in your connection and are going to run into the “Access Denied” error.
So, there you go – the problem is not with your account, but how you’re connecting to the Exchange Online Shell. Using one of these two options here should get you up and running, and back into your admin shell. I haven’t yet updated my management scripts to leverage this new module, so I’m still using an account with MFA disabled – but that’s up next!
In my recent experience with deploying Office 365 Pro Plus, the methodology for deploying updates is still somewhat mystifying for most administrators – diagrams like this one don’t really help us to understand exactly how we want to (or should) apply updates:
I mean, in theory it explains it, but in my experience it’s just gets more confusing trying to understand which updates should be applied, when they should be applied, and how they should be applied.
Let’s break it down:
Individual updates are no longer available for Office 365 Pro Plus – this means you cannot use Windows Updates, WSUS, or SCCM to apply updates the way you used to in the past. (source)
Every month a new build is released – this means that you now update from one build to the next, not applying updates based off the build you installed 6 months ago.
Update Channels – here is where find things get the muddiest… partially, I believe, because Microsoft decided to use a similar yet different naming scheme for Windows 10 update / servicing channels.
Each build is in mainstream support for 1 year – this is as long as you can defer your updates / builds before needing to upgrade to remain supportable and current.
Channels, how do they work?
Let’s talk about what these channels are and what they mean to you as you try to figure out how you’re going to manage Office Pro Plus going forward. First off – bookmark this site, and keep an eye on it to know what Channel, Version, Build, and Release Date is current: https://technet.microsoft.com/en-us/library/mt592918.aspx
This is a screenshot of the most recent update (January 2017) – but check the site for the most recent version.
Here’s how the channels break down:
Current Channel (CC) – this is the channel you’ll be on by default if you log into the portal and click the helpful button that wants you to install Office Pro Plus. The defaults for this channel are to receive a new build from Microsoft on a monthly basis, automatically. You can still control where these updates come from if you want to (more on that later), but this is the channel for early adopters, small companies that like being on the cutting edge, and are willing to put up with frequent changes.
First Release for Deferred Channel (FRfDC) – think about this as being your pilot / testing channel. If you are not just sticking with the Current Channel for your business (and most aren’t), the First Release for Deferred channel will be your power users, IT teams, and whomever you’ve identified as being a good tester in your organization.
Deferred Channel (DC) – this is where most businesses are going to put their users, and this is indeed a good idea. The deferred channel has a nice steady pace of updates (every four months), and these updates will have gone through all the testing of Current Channel users, then First Release for Deferred users before they finally make their way down to the Deferred Channel users. This means that you have about 8 months of folks testing new updates along those various channels before you push them out to your users, allowing for a much smoother update process, with much less chances of changes breaking things in your org.
Basically, the update flow looks like this – using today’s Deferred Release (Version 1605) as a reference:
June 6th, 2016: Version 1605 was released to the Current Channel (CC)
The current Channel continues to get new builds on a monthly basis
June 14th, 2016: FRfDC gets the first Version 1605 build
The FRfDC then gets monthly builds of version 1605 until October 11th, when Version 1609 is released to both the CC and the FRfDC.
Throughout these four months, the Current Channel has received Versions 1606, 1607, 1608, and 1609 with various iterations of builds throughout. Every quarter, all these updates get rolled into a single release and pushed out to both channels, and then CC starts to iterate again for another quarter.
January 10th, 2017: Version 1605 is now released to the Deferred Channel (DC) – CC is already on Version 1611, and FRfDC has started using Version 1609
The big takeaway here is that if you stick with the DC for your broader user base, you’ll be deploying updates that were first released around 8 months ago – giving lots of time for these updates to be tested, bugs reported and squashed, and feedback given to Microsoft on features and changes. This channel gives you the safest, slowest update path possible, while still ensuring that your Office installations are being kept up to date.
Don’t forget that security updates are still being applied monthly, so it’s not like your 8 months behind on security, just on features and changes.
All good? Let’s move on to the how of things…
How do I actually manage this?
Glad you asked! One of the biggest changes that admins often miss is that Office Updates no longer roll out with Windows Updates. This means Windows Update, WSUS, and SCCM cannot be used to update and manage Office the way they used to.
There are three ways that admins can apply updates for Office 365 ProPlus:
Automatically from the Internet
This is the default setting for Office 365 ProPlus
Monthly builds / updates are installed automatically
No additional user or administrative input is required
Can be used for updates even if the Office Deployment Tool is used to install Office
Least amount of administrative effort, least amount of control
As I mentioned above, if you’re already agile enough to be on the Current Channel, you’ll probably want to just leave these settings to default, and let users apply updates automatically from Microsoft servers as new builds are pushed out. If this is you, congratulations! You’re helping to test updates and make sure they’re all good before they get released to the masses in the DC 😉
Automatically from an on-premises location
More admin effort, more control
Use the ODT to download the monthly build to a network share
Computers are configured through the ODT or GPO to install updates automatically from that share
Group Policy and the ODT specify a network location for updates
This option is where you go if you want to still keep people updating automatically, but you want a little more control over the version they’re getting – the TechNet links below layout the process of how you can automate this if desired, and basically bridges the gap between convenience and control in your environment. This option will also allow you to maintain a steady cadence of updates, as you only need to configure your installs to update from a specific location, and then download whichever version you want into that updates folder.
By installing an updated version of Office 365 ProPlus
Most admin control, greatest amount of effort required
Use the ODT to download and install the latest / required version
This option reinstalls ProPlus, but only new or changed files are downloaded to the user’s computer
Using this option disables automatic updates
This final option gives you the greatest amount of fine grained control – Office Updates are disabled entirely, and users will only get the versions that you deploy to them. Use this methodology if rigid change control is required, or if you want to make sure that everyone (except your pilot/test users of course) is holding to the same version, and helps to keep your environment standardized.
It’s important to note that updates do not require local admin rights as they run under the system context, so if you’re trying to prevent users from running updates, just removing local admin privileges won’t stop these updates from applying. This also means that it’s a lot easier to manage these updates going forward, as you won’t have to go around type in an admin password in order for users to get their updates.
Given the nature of these channels (multiple release stages), it’s important that you implement a solid testing methodology in your environment. Designate a number of flexible and competent users, and put them on the FRfDC so that you know what updates are coming in your environment before they get pushed out to mission critical systems. This will allow you to defer updates if you need more testing / development time, or give you more time to prep your users for feature changes that will impact their day to day life. Once you’re comfortable that the updates are not going to cause problems in your environment, move them into the Deferred Channel and let them be released to the rest of your users.
Here’s some additional reading resources for extra credit: