Permanently Delete Office 365 Groups

If you have created teams or channels in Microsoft Teams, you likely know this creates Office 365 groups. Many other Microsoft products in the 365/Azure space create Office 365 groups. This is Microsoft’s new group which allows great flexibility across services.

However, if you have ever decided to delete a Sharepoint site or Microsoft Team, you will find you cannot create another team or site in its place. You will receive an error saying this group still exists.

This is because the group was delete as a ‘soft delete’. Meaning it’s sitting in a recycle bin for a number of days until it’s permanently deleted.

You can speed up this process. The easiest way to do this is to connect via Powershell and run the following commands

  1. Launch Powershell
  2. Run the following command if you don’t have AzureAD installed
Install-Module -Name AzureAD
  1. Connect to AzureAD
  1. Remove deleted groups
Get-AzureADMSDeletedGroup | Remove-AzureADMSDeletedDirectoryObject

If you don’t feel safe running the above command, just run the Get-AzureADMSDeletedGroup first to see what will be removed.

This will take some time to sync.


Over the weekend I’ve been installing Microsoft Server 2016 with Exchange 2016 on top. Once my SSL certificates were loaded, I got the following error when accessing OWA


I’ve seen this before on Apache. However, I was amused that this was an issue with Server 2016 since I thought that Microsoft would have disabled the Cipher suites used which cause this error. Apparently not.

A brute-force way to quickly fix this is to disable SPDY. To do this, open up the following registry key


Add the following two dword keys

EnableHttp2Cleartext 0
EnableHttp2Tls 0

It should look like the following


You can likely disable your offending cipher suites by following these guidelines.

Update 1: I solved my issue by disabling SHA and MD5 hashes on the Exchange server using IISCrypto. See below:

IIS Crypto

Error while preparing to send sharing message (Outlook 2007/2010/2013/2016)

I got the following error when I had migrated a customer from a Small Business Server to our local Hosted Exchange.

Outlook on a domain looks to Active Directory to get the auto discover information. If you run the Outlook connectivity tester on the affected computer, you will see that it returns the local SBS server autodiscover settings, even if you have configured Outlook to use an external provider.

The simplest way to fix this if the SBS server is still in used and Exchange is still installed, is to run the following commands:

Get-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverServiceInternalUri


get-autodiscovervirtualdirectory | Set-AutodiscoverVirtualDirectory -ExternalUrl -InternalUrl

This then points the Outlook client to the correct external Autodiscover service.

If you have any questions, please let me know.

message deferred by categorizer agent

I came in to work on Monday with a rather large client with no email. They run Microsoft Exchange 2007. I first logged in to the server and owa to ensure the Exchange Server was actually functioning. All services were going.

I then opened the message queue. There I saw 350 emails with the Last Error set to message deferred by categorizer agent

I haven’t actually come across this error before. Something had changed on the system. To cut a long story short, I found the issue was because of a corrupt transport agent. To find your transport agents, run the following power shell command:


You will get a list like the following

Identity Enabled Priority
-------- ------- --------
Transport Rule Agent True 1
Journaling Agent True 2
AD RMS Prelicensing Agent False 3
Connection Filtering Agent True 4
Content Filter Agent True 5
Sender Id Agent True 6
Sender Filter Agent True 7
Recipient Filter Agent True 8
Protocol Analysis Agent True 9

In the event log, I noticed the following error

An error occurred while loading the configuration for the Journaling agent. The configuration may be corrupt, or the Active Directory directory service may be down or unreachable. The last known good configuration will be used, and the Journaling agent will attempt to read the configuration again later.

This restored configuration didn’t fix the issue. I opted to disable the Journaling Agent.

Disable-TransportAgent -Identity "Journaling Agent"

Select Y and then restart the Hub Transport service.

This should fix your issue. I am still investigating a fix for the Journaling Agent. I suspect this was initially caused by a reboot when performing Windows Updates as the mail flow stopped on the same day.

Exchange 2013 Dag BSOD

We’ve recently been having issues with an Exchange 2013 DAG running CU2v2.

The server would reboot randomly with a BSOD. Exchange services would not start. I took the dump file and ran it through windbg and got the following output:

*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *

        A critical system process died
Arg1: fffffa800b415080, Process object or thread object
Arg2: 0000000000000000, If this is 0, a process died. If this is 1, a thread died.
Arg3: 0000000000000000
Arg4: 0000000000000000

Debugging Details:

----- ETW minidump data unavailable-----

PROCESS_OBJECT: fffffa800b415080

IMAGE_NAME:  wininit.exe


MODULE_NAME: wininit

FAULTING_MODULE: 0000000000000000 






ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) amd64fre

LAST_CONTROL_TRANSFER:  from fffff80230e04795 to fffff802308db440

fffff880`083419a8 fffff802`30e04795 : 00000000`000000ef fffffa80`0b415080 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
fffff880`083419b0 fffff802`30d9be2e : fffffa80`0b415080 00000000`144d2c41 00000000`00000000 fffff802`30a57794 : nt!PspCatchCriticalBreak+0xad
fffff880`083419f0 fffff802`30d12a01 : fffffa80`0b415080 00000000`144d2c41 fffffa80`0b415080 00000000`00000000 : nt! ?? ::NNGAKEGL::`string'+0x4a25a
fffff880`08341a50 fffff802`30d1880e : ffffffff`ffffffff fffffa80`0c889380 fffffa80`0b415080 00000000`00000001 : nt!PspTerminateProcess+0x6d
fffff880`08341a90 fffff802`308da453 : fffffa80`0b415080 fffffa80`0ce7c080 fffff880`08341b80 00000000`ffffffff : nt!NtTerminateProcess+0x9e
fffff880`08341b00 000007ff`5f312eaa : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`237fdeb8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x000007ff`5f312eaa


FOLLOWUP_NAME:  MachineOwner


FAILURE_BUCKET_ID:  0xEF_MSExchangeHMWo_IMAGE_wininit.exe

BUCKET_ID:  0xEF_MSExchangeHMWo_IMAGE_wininit.exe


FAILURE_ID_HASH_STRING:  km:0xef_msexchangehmwo_image_wininit.exe

FAILURE_ID_HASH:  {3f0b292e-4bc2-5c6e-99a7-f9a74df1101c}

Followup: MachineOwner

The failed process is MSExchangeHMWo. This is the Microsoft Exchange Health Monitor service.

Reading more in to this, it seems to happen when the server has an issue, like low memory, slow IO etc. It also seems to be a bug in CU2 and CU3.

A good thread on the issue can be found here.

You can run the following powershell command on a CU2 server to disable automatic reboots (BSOD).

Add-GlobalMonitoringOverride -Identity ExchangeActiveDirectoryConnectivityConfigDCServerReboot -ItemType Responder -PropertyName Enabled -PropertyValue 0 -ApplyVersion “15.0.712.24

If you have CU3 or another version, change the ApplyVersion to the specific version of Exchange. The versions can be found here.

Exchange 2013: ECP double login, error 400

After an upgrade of Exchange 2013 from CU1 to CU2 we could no longer access the ECP part of Exchange. OWA worked fine. We got a blank screen with bad request, error 400.

After a lot of searching, it looks like the upgrade for Exchange wipes out the web.config file which has all the settings for authentication on ECP.

See the following:


Be aware that this is incorrect after an upgrade. Set the authentication of basic to true again to ensure the setting is correct (note form based authentication is turned off because we use TMG).

Also make sure your internal and external url for the ECP directory is reset, as this is also wiped.

This is a known bug. See KB2871485.

Exchange 2013: 2 smtp;532 5.3.2 STOREDRV.Deliver; Missing or bad StoreDriver MDB properties

You may have got the following error when using CU1 or CU2 with Exchange 2013 when the routing plugin for multi tenancy is being used.

2 smtp;532 5.3.2 STOREDRV.Deliver; Missing or bad StoreDriver MDB properties

Now there are a couple of reasons for this, which are well documented.

The first reason is if you have a mailbox that is hidden from the address book. You need to un-hide the mailbox.

Another issue that will cause this that isn’t well documented is if you are using Email Address policies that check certain things like custom attributes or organizational units (OUs). If the user is sitting in the wrong OU, and the address policy specifies they need to be in another OU, you will get this error.

Hopefully this will be fixed soon.

Publishing Exchange 2013 OWA using Threat Management Gateway 2010 (TMG)

It still makes me sad that TMG has been retired and superseded with UAG (URGH!). That’s a whole other blog post though.

One thing that is not explained with publishing Exchange 2013 OWA with TMG is the security settings. Recently, I have been deploying an multi-tenancy solution involving single signon between Sharepoint 2013, Exchange 2013 and Remote Desktop Gateway. One of the issues is many of these products have issues with TMG 2010 out of the box, and require slight tweaking.

Today I will focus on Exchange 2013.

Go through the default wizard in TMG 2010 for publishing Exchange 2010 OWA (Web Access). You want to make sure that the Authentication Delegation is set to basic.


On your Exchange server, login in to the admin centre (ECP) and go to servers->virtual directories. Select the OWA virtual directory and change the authentication to basic.


You should also do this with your ECP virtual directory.

If you don’t set these virtual directories, you will need to login twice. When TMG authenticates, it will send you to the OWA login. Not a good look.

I also suggest reading the following link about setting the log off page in TMG.