Office 365

Stopping Skype for Business Autostarting in Windows 10

Should be simple, right?

I installed Skype for Business for Office 365 on my home PC. I had Office 365 ProPlus, and the version of Skype for Business has to match that.

Worked great, and realising I didn’t want it running all the time on my home PC, I changed the option to ‘Automatically start the app when I log on to Windows’ in the Personal options:

The next day over the weekend, I noticed that Skype for Business had decided to still launch at login. Weird, so I checked what Task Manager had to say:

Skype for Business wasn’t even listed. I started mucking around a bit more, ticking the option to automatically start, pressing OK, turning it off, pressing OK, rebooting – but every time, Skype for Business just turned up, like a strange uncle you never invite to dinner but somehow still finds out and turns up every night.

Maybe it’s in the Startup folder in the Start Menu? Is that still a thing in Windows 10? Yes it is. It’s under C:\Users\username\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup – replacing ‘username’ with what you’re thinking you should replace it with. Except, there was nothing there.

I also checked the standard Run locations in the registry, and then even searched for all instances of lync.exe which is still what runs Skype for Business… no hits that make any sense to it running at startup.

Of course, my next step is to complain on Twitter:

Interesting – Skype for Business runs at user login, but it’s not listed in Task Manager > Startup, or in the registry’s Run locations. The app even has ‘run at startup’ turned off. Not in the Start Menu Startup folder either. Don’t understand what’s triggering it…— Adam Fowler (@AdamFowler_IT) April 12, 2020

No winners in the responses – I checked sysinternaltools autoruns as suggested by Neil Clinch, and Guy Leech had a suggestion on how to completely block lync.exe from running ever, but I still wanted to use Skype for Business.

My Googling hadn’t fared any results, and I was getting desperate. I actually took a chance and read some answers.microsoft.com threads (which are usually sfc /scannow or unhelpful answers that didn’t read the question properly) and user Daniel Wherle had responded to a thread with my exact problem.

The answer was a setting called ‘Use my sign-in info to automatically finish setting up my device and reopen my apps after an update or restart’. This is hidden in Windows 10 Settings > Accounts > Sign-in options. It’s down the very bottom:

After I turned this option off and rebooted, Skype for Business no longer launched at startup. I even launched it manually, and restarted while it was running.

I turned the setting back on and rebooted, Skype for Business still didn’t autostart – that is, until I ran it with the option on, exited and rebooted.

It’s worth noting that even after completely exiting Skype for Business, lync.exe still ran in the background. I suspect this is part of the problem, because it also won’t re-open until that task is killed. I don’t have any other Office apps open, and it seems like a common enough problem that others will hit it – maybe with other programs too and this Windows 10 option enabled.

A strange one, but probably as far as I’ll dig on the issue.

Blocking ActiveSync with Conditional Access

Microsoft has announced that they’re continuing the path away from Legacy Authentication, with the decommission of legacy auth to EWS on Exchange Online on October 13th 2020. Instead of waiting for that looming date, there’s a bunch of security reasons to only have Modern Authentication for Microsoft 365.

I’ve already written up on Protect Your Office 365 Accounts By Disabling Basic Authentication and Blocking Legacy Authentication – Conditional Access vs Authentication Policies – but when I migrated from Authentication Policies to Conditional Access, I didn’t realise ActiveSync wasn’t included as part of blocking Legacy Authentication, even though it connects without MFA.

The guide from Microsoft on how to block Legacy Authentication doesn’t actually mention ActiveSync, so it’s easy to miss like I initially did! You’ll need to block ActiveSync altogether as far as I know, as it doesn’t support MFA.

Although I still think Conditional Access is easier to manage than Authentication Policies, there is one caveat; even with an ActiveSync block in place via Conditional Access, too many attempts by a user will lock their account briefly. This might cause problems or require work to get those users to clean up whatever device is trying to log in. With an Authentication Policy I don’t believe this happens because it’s blocked earlier in the sign-in process – you won’t see logs, and the account can’t get locked.

There is of course, a checkbox around ActiveSync, and a way to block it using Conditional Access, but I had mixed results in blocking it successfully until I did it exactly this way:

Create a new Conditional Access Policy and set these options:

Users and groups > All Users
Cloud apps or actions > Select Apps > Office 365 Exchange Online
Conditions > Client apps > Tick both ‘Mobile apps and desktop clients’ + ‘Exchange ActiveSync Clients’
Grant > Block Access

In the Users and Groups section, you can narrow this down from ‘All Users’ for testing or for a gradual rollout.

The user experience is interesting on this one – they can still sort of authenticate, but instead of getting their emails, they will see a single email advising that their access has been blocked:

On top of this, you can use Azure AD to audit who might be using ActiveSync before you put any sort of block in place. As per usual, there’s a good Microsoft article on Discovering and blocking legacy authentication which can walk you through this, but in short:

Via the Azure Portal, go to Azure Active Directory > Users. Under Activity, go to Sign-ins. Click Add filters, and choose Client App > Tick the three ‘Exchange ActiveSync’ options and press ‘Apply’. You’ll see the last 7 days of sign in attempts using ActiveSync, which should give you an idea of how many users are using it, and who.

Blocking Legacy Authentication, plus blocking ActiveSync will give you a much more secure environment, protecting from account attacks.

MyAnalytics is Coming (for the rest of us)

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.

Converting a user mailbox to shared in Exchange Online Hybrid

This is a useful process a lot of companies follow when an employee departs: Instead of deleting the mailbox, or continue to leave the mailbox in place and pay for licensing, it’s possible to instead set it as a shared mailbox and keep the data there for free.

There are some catches to this, such as the maximum amount of data is 50gb. You also can’t delete the user’s account, but it can be disabled and moved.

Setting the mailbox from User to Shared in Exchange Online is easy (from docs.microsoft.com):

In the admin center, go to the Users > Active users page.

Choose the user whose mailbox you want to convert.

In the right pane, choose Mail. Under More actions, choose Convert to shared mailbox.

…but there’s two tricks I’ve found when doing this in a hybrid environment. First, docs.microsoft.com says to update the status of the mailbox for Exchange On-Premises:

If this shared mailbox is in a hybrid environment, we strongly recommend (almost require!) that you move the user mailbox back to on-premises, convert the user mailbox to a shared mailbox, and then move the shared mailbox back to the cloud.

That’s a tedious process to do just to make it shared. As they point out, you can change some AD attributes locally to get around this, but there’s still some scenarios where it might get set back as a user, have no license, and end up getting deleted.

This other article on support.microsoft.com however, mentions the main way of getting around this: by setting the account’s msExchRemoteRecipientType and msExchRemoteRecipientTypeDetails attributes to the corresponding values that would match it’s state in Exchange Online:

Set-ADUser -Identity ((Get-Recipient PrimarySmtpAddress).samaccountname) -Replace @{msExchRemoteRecipientType=100;msExchRecipientTypeDetails=34359738368}

This 1 line command will set the attributes correctly, you can check via PowerShell or the Exchange Management Console to see that the mailbox will now show as ‘Shared’.

Update 3rd March 2020: Last time I tried the above, it didn’t work. The good news is that as long as you’re on Exchange 2013 CU21 or later and Exchange 2016 CU10 or later, you can just use the command:

Set-RemoteMailbox -Identity user -Type Regular

This fixed the on-premises status of the mailbox, even though I’d already moved it online. So, worth trying first before doing anything, as it should correctly do both if you Thanks Arttu Astila for the tip! /End of update

The other problem I’ve seen is if a mailbox is Unified Messaging (UM) Enabled, and converted to Shared. You’d think that it would either just lose it’s UM status, or let you configure the UM settings after the fact; but neither are correct. If it’s holding onto an extension number as part of UM, even in it’s Shared Mailbox state it will continue to hold it, and block any other account from using the extension in the future.

To get around this issue, the account will need to both be changed back to a user account from shared, and given a license that supports UM. If you try to disable UM on the account with either of these requirements, you’ll see an error like these:

User testuser@domain.com is already disabled for Unified Messaging.

License validation error: the action ‘Disable-UMMailbox’, ‘Identity’, can’t be performed on the user ‘Test User’ with license ‘BPOS_S_Standard’.

With all of the above, changing a user to a departed mailbox in a hybrid environment with Unified Messaging should be:

  1. Disable Unified Messaging on the user
  2. Set the attributes of the AD account as shared
  3. Set the Exchange Online mailbox as shared

It should work well if you do things in the right order, but it’s easy to not be aware of this and get things into a mess.

There’s also the scenario where you might create an account, give it Office 365 licenses and have a mailbox automatically created before you did it on-premises, or used Exchange On-premises to create the mailbox remotely.

You can fix that by using this script from Adaxes (doesn’t need their software!) which will tell on-premises Exchange about the mailbox and create the record.

I’ve come across another blog that goes into some of this http://jetzemellema.blogspot.com/2016/02/convert-user-mailbox-to-shared-in.html but I haven’t needed to change the license status, but it’s worth mentioning in case there’s a scenario you hit where you do.

OneDrive for Business Rollout Considerations

If you’re managing OneDrive for Business in your organisation, there’s a lot to consider – more than what you’d think until you start looking into it. I’ve just gone through this, so thought it was a good time to document and share what I found with my recommendations.

There’s two major areas to review settings in:

admin.onedrive.com

You may not know this even exists as it’s still in preview, as OneDrive for Business fully functions without ever having to go here. The OneDrive admin center at https://admin.onedrive.com/ has some nice settings worth checking out. Some of the settings were already available in other areas, but this gives a central point to manage them.

Sharing: Under the Sharing section, there’s a few settings I’d recommend changing. The defaults are much more open – allowing users to create shareable links that don’t require a sign-in (which is really a bad idea when you’re sharing work information!), as well as the default link type being ‘Shareable: Anyone with the link’.

I’d recommend having the default ‘Direct: Specific people’ when sharing a link, and restricting the ability to have anonymous shareable links at all. This way ensures that data only gets shared to the people the end user chooses, and nobody else.

Sync: ‘Allow syncing only on PCs joined to specific domains’ is off by default, and you’ll need to look up your domain’s GUID to enter it in. This is good for data leakage, do you really want someone’s home PC automatically downloading all work data? This won’t block them from accessing OneDrive information at all as it’s available via web and Android/iOS apps, but none of those solutions automatically sync content. You can also block Mac OS if you don’t manage any in your company.

There’s also the option of blocking syncing of specific file types – I can’t think of a particular reason for this though. OneDrive already has AV built into it, as does your PC with Windows Defender, AND you should have Applocker in place to block running unwanted executables… but it’s still worth noting the option.

Storage: The default ‘Days to retain files in OneDrive once a user account has marked for deletion’ might be missing a word, but it’s default value is 30. You can go all the way up to 3650, which is 10 years minus a few days for leap years. I don’t have to worry about this data or pay extra for it, so I’d rather have it retained just in case.

There’s also another option where on departure, the manager based on the AD/AAD field of the departing user will be granted access to their OneDrive, which is a nice automated way of having someone check the contents in case anything needs to be saved out. That setting lives in the SharePoint Admin center, fully described in the above link.

Device Access: Worth noting that you can restrict access from certain IP addresses, but in the real world I don’t see many companies doing this unless you really want to keep your OneDrive data internal.

If you’re in a position to disable this other option though, removing the ‘Allow access from apps that don’t use modern authentication’ is good security wise, and ties into my other post Protect Your Office 365 Accounts By Disabling Basic Authentication.

There are other options in the OneDrive for Business Admin Center, but nothing I personally considered changing.

Group Policy

This is probably where you’ve already started. Make sure you’ve deployed the latest ADMX files, and review all the settings. Here’s the key ones I’d recommend looking at, some are computer based and some user:

Enable OneDrive Files On-Demand: This makes just the stubs of files download to the OneDrive client, then download the full file when requested. There might be some pushback on not having instant access to a file when wanted, but when you tie this into Known Folder Redirection (below) and have users that move around a lot, this should save bandwidth and disk space across your fleet. I have this one enabled.

Prevent users from using the remote file fetch feature to access files on the computer: I’d definitely have this one off as it lets users access the entire contents of any PC they’re signed into (where their account also has access to the local files of course), remotely. It could easily lead to data leakage when you’re opening up such a big door.

Delay updating OneDrive.exe until the second release wave: If OneDrive becomes important to your users (which it should, yet again with Known Folder Redirection), then you probably want to avoid getting a new release that has a bug. Sit back and wait for the second release wave to make sure you’re getting a more stable update each time. Enabled with maybe a few users having this Disabled for piloting/testing.

Prevent users from synchronizing personal OneDrive accounts: I enabled this one, as with the above settings I’ve already allowed a method that users can get and work on the files they want from anywhere. I can also monitor this and produce logs if required. Someone’s personal OneDrive I have no visiblity or control over, and there’s really no need to allow this.

Silently move Windows known folders to OneDrive: Once you’re ready and fully deployed with OneDrive, this is the next great feature to check out. It deserves it’s own blog post later, but you can silently configure the user’s Desktop, Documents and Pictures folders to live in OneDrive, rather than the local PC. This lets users access the same data wherever they log into, with the extra benefit of doing it in the background after the user logs in – no login delays. It’s like having an important part of roaming profiles, without the headaches. More info here: https://docs.microsoft.com/en-us/onedrive/redirect-known-folders

If you’d originally disabled OneDrive via GPO through the policy Prevent the usage of OneDrive for file storage then just disabling that policy should be enough, as long as you still have OneDriveSetup.exe running at login via the Run registry hive against the user. If you removed that, you may have to add it back in.

I found this method to be useful – to create the value HKEY_Current_User\Software\Microsoft\Windows\CurrentVersion\Run – Reg_SZ value type OneDriveSetup with value data C:\Windows\SysWOW64\OneDriveSetup.exe /thfirstsetup – but only applying this if the OneDrive registry value didn’t exist. OneDriveSetup should remove itself if successfully run, and will also create OneDrive meaning the setup key won’t get put back again.

If you see what a new user gets the first time they log in assuming no OneDrive cleanup has happened, is the exact same OneDriveSetup key as above. In my testing, having other switches against OneDriveSetup caused issues.