IT

Hide ‘Do not forward’ in Outlook

If you’ve noticed this option in Outlook, you might wonder where it comes from:

On a new/reply email window in Outlook, under the ‘Options’ tab is a button called ‘Permission’ (which in the future based on the time of writing, is changing to be called ‘Security’). This by default has three or four options, which seem to be dependent on the version of Outlook being run (MSI vs CTR). Click To Run has another called ‘Encrypt-Only’ which I haven’t tested yet.

These options are actually using Azure Information Protection (AIP) to encrypt your email. That’s a giant topic in itself, but the one liner is that wherever you send an encrypted email to, needs to sign in to view the message. In some scenarios this works seamlessly, such as sending to an external user also using Exchange Online. In other scenarios they’ll need to click a button to log in and view the email via their browser.

The ‘Tenant name – Confidential’ and ‘Tenant name – Confidential View Only’ are default AIP labels. You can view/edit these by going to your Azure portal and looking under Azure Information Protection > Classifications > Labels. 

As you’ll see in the screenshot above, the two labels I mentioned are listed, and you can go into those and disable them if you don’t want them to appear for your users (there’s a toggle for ‘Enabled’ set to ‘On’, set that to ‘Off’). You could also completely disable Azure Information Protection, but that might cause you other problems if you want to use AIP in any way.

You might be wondering why you’d want to turn these off, encryption and security is good right? You might not be ready for users to start using this yet for support reasons, you might have a different method of securing emails, or you might be using a 3rd party backup system. That backup system won’t be able to read encrypted emails by default – so unless you can get that working somehow, you will only have copies of emails that contain a link to the actual content that require the right access to get to the contents – not a true backup.

Getting back to the title of this article – Do No Forward. If you’re at this stage, you may have noticed that it’s not actually a label listed. As covered in this documentation, it’s inbuilt rather than being a customisable policy, template or tag.

There is a registry trick to disable this from Outlook though, which was given to me by Microsoft Support:

Open registry key editor:
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\DRM
14.0 = 2010
15.0 = 2013
16.0 = 2016
2.On the Edit menu, point to New, and then click DWORD (32-bit) Value.

Type DisableDNF, and then press ENTER.

In the Detailspane, right-click DisableDNF, and then click Modify.

In the Value databox, type 1, and then click OK.

Exit Registry Editor.

This will at least grey out the option so it can’t be used. The option will still be usable in Outlook via Web, and if I find a solution to that I’ll update this post. As far as I know at this stage, it can’t be hidden or removed.

Exchange Online Migration Clears ‘Recent’ Document Lists from Word and Excel

I struggle to fit these issues into a short but descriptive headline sometimes :)

This issue is a little strange. If you didn’t know any better (like me), you’d expect the location of a user’s mailbox to have no impact whatsoever on the function of ‘Recent’ document history inside of Microsoft Excel and Word, but it actually does.

I found this out the hard way of course, when a couple of staff mentioned their recent lists had disappeared and it co-coincided with their Exchange on-prem to Exchange online migration.

After some digging, I came across this Reddit post: 
Users losing Recent Documents lists in Office 2016 due to upgrade to ADFS. It’s the same problem with a slightly different root cause, and goes into a much deeper technical explanation than what I’ll do here.

The short of it is that the Office applications detect what sort of login you’re using – if it’s Active Directory (AD) or Azure Active Directory (AAD). When that state changes, it uses a different registry path for a few things, including those recent documents.

Without knowing for sure but based on my testing, it must be doing some check to see if the associated account’s mailbox is in Exchange Online or not – and if not, it considers it an AD account. It doesn’t matter if you already have the users in Azure AD, Single Sign on and all that other good stuff set up – the single change of changing the mailbox location to online triggered the change for me.

For an AD account, the history paths are saved in the registry here:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Word\User MRU\AD_1234567890 (the number on the end is some sort of unique GUID).

For an Exch account, it’s in this slightly different path:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Word\User MRU\ADAL_1234567890 (again, unique GUID at the end).

In case you were wondering, MRU stands for ‘Most Recently Used’. AD is to do with on-prem Active Directory, and ADAL is (according to that reddit post) Azure Active Directory Authentication Library.

Also note the example above is for Word, there’s corresponding paths for other Office applications such as Excel.

There’s two subkeys below this key, one for File MRU and the other Place MRU.

The good news on hitting this scenario is that the values can just be exported, the path changed and re-imported. To do this, via regedit find the registry key that has the values you want (probably the AD one) and right click > export.

Find the file you exported and use notepad to do a find and replace on all the entires for AD_1234567890 and replace to the new value (which you can find from just looking in the registry).

Now, re-import the registry file and you’ll have all the recent document paths restored.

This should only be a one time problem for migrations, and only for people who had a bunch of document paths saved in there and can’t find where they are easily.

Disable Windows Defender Summaries via Registry

Windows Defender does some great stuff, but in my opinion one of the more ‘noisy’ things it doesin Windows 10 is provide a frequent notification to say it’s working but hasn’t found anything.

Many users may find this notification unnecessary and breaking their work focus just to be told that their PC is fine. Especially in a business environment, they’d think that is someone else’s problem.

Windows Defender Security Center Settings

A user can turn these off themselves of course, in the Windows Defender Security Settings page under Virus & threat protection notifications. It’s possible to turn off all informational notifications, or untick certain types.

Although there is an inbuilt Group Policy to also turn off informational notifications, to me I’d still want users knowing a threat was found or something was blocked – those are useful to the user. However the recent activity and scan results is the one I’d suggest disabling, but there’s no Group Policy for that.

Luckily this is just a single registry key which I’ve found through using Procmon:


HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender Security Center\Virus and threat protection\

REG_DWORD: SummaryNotificationDisabled

Value: 1 (decimal)

This setting can be rolled out through Group Policy (even as a run once and don’t reapply) if you’d like users to have control over turning the setting on.

Microsoft Software Ready For Betting?

If there’s one thing difficult to accuse modern American tech companies of, it’s inadequate preparation. While the consumer-facing sides of these companies deal with exciting products, software updates, and things of this nature, the same companies are constantly working behind the scenes in order to enrich their offerings. This includes development, marketing, maintenance, and perhaps most interestingly, concept consolidation and patent acquisition.

There are constant examples of major tech companies quietly filing patents long before a product actually goes to market, from a given type of screen for a mobile phone to current rumors of Apple’s designs for augmented reality glasses.

One recent example of this that seems to have flown under the radar is Microsoft’s file for Patent No. 0125691. This came to light late in 2016, with notes that the patent application includes words and phrases like “real-time” and “determine payout of event” that appear to point toward a gambling application. Said one article on the development, it could be a critical piece of a future with widespread legal gambling in the United States.

In 2016, that still sounded very much like a future, because there was little publicly evident momentum toward establishing legal betting beyond places like Nevada and New Jersey. That all changed early in 2018 however, when a Supreme Court decision altered the betting landscape significantly. It remains up to individual states to legalize the activity (and you can track their progress here), but to put it in clear terms, it’s now legal to make it legal, if that makes sense. And that means the environment Microsoft appears to have been preparing for with this particular patent is closer to materializing than we might have once believed.

As to what that environment will look like, and what sort of activity Microsoft could ultimately get involved with, we might best look to examples set in countries where sports betting is legal. This has been the case in the UK for some time for instance, and the same can be said of Australia. In these countries there are numerous betting sites available, and they tend to be accessible both online and via mobile. It may well be that Microsoft is aiming for the higher end of all this as well.

It’s recommended that people looking for modern betting sites pay attention to in-play services, which essentially allow for real-time gambling and decision-making, but which aren’t necessarily available through some older platforms. Given that the patent, as mentioned, references the term “real-time,” it would appear that Microsoft is up-to-date on what bettors look for in modern sites or applications.

It’s still not crystal clear how or when the patent might be used. But we may find out sooner than we thought thanks to the progress of legal betting in the U.S., and it certainly sounds as if the tech giant is going to have its own services available in this area. 

Azure AD Sign-in via Google Chrome and Conditional Access

While testing MFA, Conditional Access and all the other good stuff Azure AD provides, I came across this scenario:

Conditional Access configured to require MFA if the user wasn’t on an Azure AD Hybrid PC, or coming from an internal IP.

User on an Azure AD Hybrid PC, but on an external IP.

User uses Chrome to access a Microsoft resource, and gets challenged despite being on the Azure AD Hybrid PC.

It seems that the sign-in process isn’t aware of the state of the computer when using Chrome- but there is an easy fix: deploy Windows 10 Accounts extensions for Chrome.

This is really easy to do via Group Policy.

  1. If you don’t already have them, get the ADMX Group Policy files for Google Chrome and deploy into your environment
  2. Under User Configuration > Policies > Administrative Templates > Google > Google Chrome > Extensions, configure the policy ‘Configure the list of force-installed apps and extensions’:

3. Change the radio button to enabled, click ‘Show’ and enter the value for the add-in

ppnbnpeolgkicgegkbkbjmhlideopiji;https://clients2.google.com/service/update2/crx

4. Do your normal process of configuring the Group Policy object to target the users you want, run a gpupdate and see the addin silently turn up in Chrome. The only user impact will be a visible Windows logo to the left of the Google Accounts area in the top bar of Chrome.

Peter van de Woude has documented how to do this via registry, so read his post if you want info on how to do that –  as well as how to then deploy via Intune and PowerShell script.

Worth doing if you use Azure AD connect, and highly recommended if you’re using Conditional Access.