MyAnalytics is an extension to Microsoft 365 which provides productivity insights. It looks at what you do over email, OneDrive for Business and Skype for Business Online/Teams, and collates the data to present it with statistics.
The documentation for how this product works is quite good and worth a read. There’s privacy considerations in any product that’s scraping data, but they seem fairly well addressed. Two main points are that the data for MyAnalytics is processed and stored in the user’s Exchange Online mailbox, and nobody but the user can see this data (including system administrators).
MyAnalytics has been around for a while, but mostly for Office 365 E5 / Microsoft 365 E5 customers so many people have not heard of it, or have no experience in it. Microsoft are changing who gets access to this data, and are currently rolling out Digest emails to E3, E1 and Business customers.
If you have the feature already turned on, then your users can probably already access their dashboard at https://myanalytics.microsoft.com/ and start checking it out.
MyAnalytics is controlled by a license under the Microsoft 365 product. Many people probably have all the components on, and therefore although users have had access to this product, it hasn’t really been visible. The Welcome email comes first, and it seems to be rolling out right now to Targeted Release users in Microsoft 365.
Beyond just turning MyAnalytics on, there’s a few admin controls available at the tenant level and user level. You’ll need to consider items like ‘should users be opted-in by default, or opted-out’ if there are concerns around data scraping – even though this all lives in your Microsoft tenant, there could still be staff that are not comfortable with this.
Nascar use MyAnalytics if that helps you point to another company using it:
As you can see, I’ve linked to a bunch of Microsoft documentation around this rather than rewriting what they have – always nice to see quality doco!
It’s worth checking out MyAnalytics now and deciding if it’s something you want – at least check the state of your settings before users start getting Welcome emails!
Update 20th September
The product group have advised me on one extra tip – disabling the ‘Weekly insights email‘ option at the admin end will actually disable the Welcome email too – documentation to be updated shortly.
While testing Always On VPN in Windows 10, I discovered an issue where users couldn’t access the Network Connections settings to see what the VPN profile was up to.
Network Connections is accessible in a few ways, including via Control Panel\All Control Panel Items\Network Connections, or ‘Change Adapter Options’ under Settings > Network and Internet > Ethernet. It was locked down, but I wasn’t sure why.
If I changed a user to be a local administrator, I could then access Network Connections. I couldn’t find any reason why it could be locked down, until I stumbled across this old Group Policy Setting:
Remote Network Connections from Start Menu
Based on it’s name, it should be just doing exactly what it says. Plus, the newsest desktop OS listed for support is Windows Vista.
However, as the help explicitly says:
Network Connections still appears in Control Panel and in File Explorer, but if users try to start it, a message appears explaining that a setting prevents the action.
And that’s exactly what it was doing. After removing the setting from being configured and running ‘gpupdate’, I could immediately access Network Connections again.
Another reason to make sure your Group Policy settings are cleaned up – this setting was set over 10 years ago, and took this long to discover and remove!
AKA How to force certain websites when opened in Edge, to instead open in Internet Explorer.
Update 15th June 2022: Note that there’s another way to now do this, using Enterprise Site List Manager which is an in-browser version of the standalone Enterprise Mode Site List Manager tool. Check it out using edge://compat/SiteListManager and here’s the official documentation: https://docs.microsoft.com/en-us/deployedge/edge-ie-mode-site-list-manager To access this via the Microsoft 365 admin center: Settings – Microsoft 365 admin center
Update 17th January 2020: The New Edge is out, and there’s 1 extra Group Policy to do: Enable ‘Configure Internet Explorer integration’ and set it to ‘Internet Explorer Mode’ to open inside Edge as IE, or ‘Internet Explorer 11’ to open sites seperately in IE11 . The rest of this article still applies and is needed to make this work. Official documentation on docs.microsoft.com
Original Post:
Microsoft Edge is undergoing a big change with the underlying platform being migrated to Chromium – things will change with that (along with a new Internet Explorer mode) but that doesn’t help right now.
Many companies have certain websites they need to use that either require Internet Explorer, or work best in Internet Explorer. This isn’t about what browser is ‘best’, but some solutions were designed with only Internet Explorer in use.
Getting users to use the right website in the right scenario can be a pain, and every user seems to have their own opinion on what browser they prefer to use. Microsoft Edge has a great solution for this – Enterprise Mode. There was also an Enterprise Mode in Internet Explorer that worked in a similar way too, where you could force certain sites to run as a certain version of IE for compatibility reasons.
This is quite easy to set up, but I’ve found the existing documentation rather confusing to follow and doesn’t give an end to end explanation – or documentation is rather outdated and was written when the feature first came out, with a lot of options changing since then.
Enterprise Mode Site List Manager will start off blank. Click the ‘Add’ button on the bottom, type in the URL of the site you want to use (don’t worry about http or https if you want to catch both). You then tell it what to do with that URL – Open in IE, Edge, or do nothing. Since we’re opening everything in Edge except what we want in this list, open in IE11 is the option we want, and leave it at the default IE8 Enterprise Mode (or change this if you need a different compatibility mode).
There’s two parts to maintaining a list – Exporting/Importing lists, and Saving as XML:
Once you have a record to test, go to File > Export. This will save your details into an .emie2 file, and put that somewhere central and safe. The idea is that you’ll need to import that file list to make a change, then export again. If you don’t do this, you won’t have a way for others to get the list of sites and make changes by importing that file at a later date. It has in-built version control (this is important, more later), in the screenshot above you can see it’s version 5.
Then, you can save your URL to an XML file. This is what Edge will read when it launches. Either save this file centrally where everyone can read it (no write access required, just read), or copy it to everyone’s computer locally via GPO. Personally I’ve just put it in a central location.
Step 2 – Configure Group Policyor Intune
I’m using Group Policy, but the Microsoft Documentation mentions Intune is supported too – we’re only changing registry settings, so that makes sense.
Turning on Enterprise Mode can be done at either the Computer or User level, and is under > Policies > Administrative Templates > Windows Components > Microsoft Edge > Configure the Enterprise Mode Site List.
Enable this setting, and in the options enter the path of where your XML is – e.g. \\server\sharename\edge.xml – or C:\Data\edgesettings.xml. Although the Group Policy says URL, it’ll accept UNC paths or drives.
If you’ve used a Computer Configuration setting, gpupdate then reboot (or reboot twice). To tell if the setting has applied, check the value of the registry setting:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\MicrosoftEdge\Main\EnterpriseMode
or
HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\MicrosoftEdge\Main\EnterpriseMode
SiteList = The path you entered in the Group Policy setting.
If you’re see that, great! Group Policy is working. One caveat if you have System Center Configuration Manager (ConfigMgr) – it can potentially use this setting also as per this technet thread which is exactly what I had. I was testing a user policy, but this was configured at both the user and computer levels so my user setting was being ignored. I’m not sure if this is still used, but worth being aware of.
Version control is also recorded in the registry. It lives under:
regardless of the SiteList being under Computer or User. There’s a few catches with this – first, it’ll only show up after Edge is launched, and you wait ~65 seconds. It’ll show the same version as what’s contained in the XML, which was the version we saw in Enterprise Mode Site List Manager.
If you have the ConfigMgr setting, or have ever had Enterprise Mode for Edge enabled in your environment, then the version might already exist and be higher than what you’ve tried to deploy. On my PC, I saw version 28000 something – that’s a lot of versions.
You’ll need to either delete that value for everyone to start back at 0, then after Edge is launched per user, it’ll update to whatever your XML file contains, or update the version in Enterprise Mode Site List Manager to a higher number than whatever’s out there in your environment.
To change the version in Enterprise Mode Site List Manager, on the computer with it installed navigate to
C:\Users\your username\AppData\Roaming\EMIESiteListManager\ – in that path should be a file called SiteList.xml.
That file should have the first line as <site-list version=”5″> or whatever the current version is, and you can just change that ‘5’ to whatever number you want. Open Enterprise Mode Site List Manager and you’ll see that updated version number, which will then get written +1 to the XML file next time you save it out.
That’s really it – it’s simple, but there are a few catches I ran into when testing. Once this is in place, if a user goes to a site that you’ve listed in the XML, a new window opens in IE and goes to that site instead. It’ll also support subsites, so you don’t need to sent traffic for an entire domain like adamfowlerit.com there, it could be adamfowlerit.com/news and only hits to that subdomain will be triggered.
There’s a few other Group Policy settings around this such as forcing all intranet sites to go to IE, you’ll need to work out what’s best for your environment.
I’ve already written a post on why Legacy Authentication (Basic) is bad, and Modern Authentication is good. At the time of writing, Authentication Policies were the way to go to block Legacy Authentication methods. Of course, things change and there’s now a better* option to look at – Conditional Access.
I’ve also covered Conditional Access before, and it’s really hard to fault the solution. There are now Baseline policies deployed by default (still in preview though) to Azure AD tenants with recommended best practices:
Conditional Access Baseline Policies
One of these is for blocking legacy authentication – but I’m not going to recommend you turn this on (at least for starters, it’s good at the end when you know you have full modern authentication support), as it’s a tenant wide setting that has no exceptions if you need to allow legacy authentication for an account (unlike Require MFA for admins, which does allow exceptions).
Instead, you can create your own policy that does the same. This means you can gradually roll it out, and put exceptions in place until you either work around them, or live with them. If you have a requirement for an account that requires legacy auth, then you need to consider how else you’ll protect that account – can you use other Conditional Access policies to restrict it to a certain region/locations, certain apps, platforms etc – lock it down as much as you can, and make sure the account has a long unique password.
The single important setting to block legacy auth via a Conditional Access Policy is blocking access to ‘Other clients’ via Client apps:
Microsoft have a full guide on how to set this up on docs.microsoft.com.
If an account has their access or signin blocked due to an Authentication Policy, it’s not logged. You can look at the user in Azure AD and check the sign-ins, but you won’t see anything. However, if it blocked via Conditional Access, you’ll have a nice log entry showing you it was blocked:
Side note: Although in this example I was logging in from Australia, I was trying to connect to Exchange Online via PowerShell. That seems to often be detected as being in the US, so be careful with region blocking.
The other reason is that Authentication Policies can take up to 4 (!) hours to apply, although it’s often more like an hour. That is a long time to wait, and you just have to keep waiting and trying until it works – except if you did it wrong, you won’t know and you’ll keep waiting. Or, if you need to unblock access while rolling out, it’s a long time to roll back.
Authentication Policies do have their place though, they give more granular control over what you want to block or not – say you know you want to block POP3 access company wide, but not IMAP – that’s possible in there, but not via Conditional Access.
Unless you have a good reason to use Authentication Policies, just use Conditional Access (and assuming you have Azure AD Premium P1 or P2 licensing to actually let you use Conditional Access, and if you are using Azure AD you should be on that licensing anyway). It’ll make your life easier!
This one had me stumped for a while, and I even asked on Twitter with a large amount of replies (thanks everyone who did!) but none that I could get to work, or that weren’t overly complicated requiring the compiling of code.
None of those worked remotely for me in a Windows 10 environment – but I thought Handle from the SysInternals Suite would be the best bet. Running locally, it did exactly what I wanted – a giant list of every file open, and say what process had it open (like WinWord.exe).
Using PSExec with Handle however, causes it to forever wait for something. On the remote PC, it definitely launches handle.exe and handle64.exe, but they have no activity. I thought it might be the EULA prompt getting stuck somewhere, but there’s a registry setting that will autoaccept that prompt, and putting that in place didn’t help (but I did check locally and it was skipping the EULA agree prompt. Thanks to this blog post explaining the reg key required https://peter.hahndorf.eu/blog/post/2010/03/07/WorkAroundSysinternalsLicensePopups which was:
I added this to the remote machine under both the user logged on to the remote device, and the user I was connecting as, with no luck.
After a bunch of Googling and trying solutions, I ended up finding this thread on stackoverflow. One of the answers with 0 votes (which can be easily overlooked) was a PowerShell script, invoking the command remotely, from a user called A.D – thank you A.D!
I’ve barely modified it for my purposes, but if this helps you please go vote his post up on stackoverflow (I did but don’t have enough rep for it to show):
$computerName = 'computername'
$stringtoCheck = 'test' # String you want to search for, can be blank by removing text between '' quotes
$pathtoHandle = 'c:\temp\handle.exe' #location of handle.exe on the remote server.
Invoke-command -ComputerName $computerName -Scriptblock {
param(
[string]$handles,
[string]$stringToCheck
)
"$handles /accepteula $stringToCheck" | Invoke-Expression
} -ArgumentList $pathtoHandle,$stringtoCheck
The script requires handle.exe to be on the remote computer under C:\Temp, and that of course you have admin rights to the remote PC with the account this script is being run. Beyond that, it’ll show back all open files that match the variable set in $stringtocheck across any of the results – it could be the path, the process that has the file open etc.
Why would you want to do this remotely at all? You might be troubleshooting something to do with open files and not want to interrupt the user. You might have a reason to see what files the user has open, or maybe it’s a locked PC and the user left.
Hope this helps others as it was a much harder task to accomplish than I assumed.
