This was returning “Failed to modify preferences” on the Add-MpPreference cmdlet and the error code 0x80070073
To fix I needed to uninstall Windows Defender and reboot and then reinstall it.
This was the following cmdlets, with the reboot indicated between them:
Uninstall-WindowsFeature -Name Windows-Defender
Install-WindowsFeature -Name Windows-Defender
Install-WindowsFeature -Name Windows-Defender-GUI
#Reboot here (again)
Once this was done I was able to add Defender exceptions. The addition of exceptions also failed when done via the Defender Settings application as well (it asks you to authenticate and fails). This also worked after the uninstall/reinstall:
Article Depreciated: Microsoft now auto-hides the Calendar icon in Teams if your on-premises Exchange Server is not reachable via AutoDiscover V2 and at least Exchange Server 2016 CU3 or later. Once you move your mailbox to Exchange Online (or a supported on-premises version), assuming you did not do any of the below, your Calendar icon appears in the left rail shortly after mailbox migration, though I have seen it take six hours and needs a Teams client restart as well
In Microsoft Teams, you have a calendar (previously called meetings) icon in the main display that shows your diary and meetings etc. – except it does not work if your mailbox is not either in Exchange Online or, if if your mailbox is on-premises, you are not using Exchange Server 2016 CU3 or later.
The reason for this is that the Teams calendar uses AutoDiscover v2, which is only supported by Exchange Server 2016 CU3 and Exchange Online (note that CU3 is not the current version of Exchange Server 2016 and versions later than CU3 also support AutoDiscover v2).
This means that if you have an earlier version of Exchange Server on-premises then the calendar in Teams is not functional. This raises IT support calls as users expect it to be available, and this impacts your deployment of Teams as it appears broken.
So how can we fix this. Well clearly migrating to Exchange Online or installing the 2016 or later version of Exchange Server is the obvious option from the above, but there is another option to work around this issue. The “fix” is to remove the calendar icon from Teams. This does not stop you booking meetings, as you can still do that in Outlook with the Teams add-in or in the Outlook mobile client, where Teams meeting support is rolling out as I write this blog. If I remove the calendar icon, then the source of the errors disappears, but Teams is not really adversely impacted.
So this is what we start with:
And we remove the icon by creating a new App Setup Policy in the Teams Admin centre and then deploying that policy to all your users (with on-premises mailboxes on older versions of Exchange, or those not using Exchange for calendaring). You can easily roll this out as a test, though its about 24 hours for the effect to be seen, and then roll it out in bulk for all your impacted users. We will cover all this below:
1. Creating App Setup Policy
In the Teams Admin centre (https://admin.teams.microsoft.com) expand Teams Apps > Setup Policies and create a new policy. This policy is based on your current Global policy.
Select the Calendar app and remove it from this new policy. You should see something like this:
Here I have created an app policy called “With OnPrem Mailboxes” and removed the Calendar app from it.
2. Applying App Setup Policy To A Test User
Once you have the policy ready, its time to test it. Policy changes will take 24 hours to apply (so say the docs) and I found on my testing it was 18 hours when I ran through these steps – so this is not quick!
To make sure your changes work, the plan here is to deploy this new policy to a few selected individuals in the Teams admin centre.
Find the first user and click on their name. In the details page you will see the policies applied to the lower left:
Click Edit at the top right of this section and change the App setup policy to your new policy:
And click Save:
You will see your new policy in the list.
Repeat for the rest of your test pool of users using the portal. We will not use the portal for deploying it to all users though, that will take too long!
Next day, these users should see something like this – no calendar:
3. Applying App Setup Policy To All Users
To apply this change to all users once your test users are happy we will use PowerShell, and we will use the Skype for Business Online PowerShell cmdlets (not the Teams PowerShell!).
The following one-line PowerShell, once you have connected to your tenant, is:
This gets all your users and applies a new Teams App Setup Policy to each of them. This works initially with this problem, as we assume all users are affected. If only a subset of your users are on-premises, then do not use this cmdlet to apply the initial change, but use the below to be more selective.
Within 24 hours the Calendar app will disappear from Teams for your users and they will not be phoning the help desk with issues that none of you can easily fix!
4. Applying App Setup Policy To Selected Users
The above cmdlet is a single run – it does not affect later and new users, nor is there a concept of a default policy that you can set as the one each new users gets. So every so often depending upon how often new users start employment you will want to run the below:
This gets all users where they do not have the selected App Policy already set and sets this just for these users. This is quicker than setting it for all users regardless.
You can use other filters to select users – for example, you could look for users without an on-premises mailbox and then run the ForEach against each of these users instead – this would work in a hybrid deployment.
When you are in a hybrid deployment and you move mailboxes to Exchange Online from on-premises, you will want to set those users just moved back to a policy that includes the calendar app. The same would go for organizations migrating to Exchange Server 2016 with inbound AutoDiscover from Office 365. Here you could use something like importing a CSV file of mailboxes being migrated (the same list you used to build the migration batches in the first place would do) and then run the ForEach for each item on the CSV file.