Making changes to DFS Namespaces in Windows Server

One thing I always seem to dread and battle is making changes to DFS Namespaces and shares. In addition, I also seem to struggle with the simple concept of reboot or even restarting a service, but that’s a topic for another day. (Or is it?)

In this case I was doing some minor file server cleanup at the end of a day, and moving data around. Part of this process was to delete a couple DFS namespaces and re-create them pointing to the new locations.

I ran into issues deleting the namespaces where the DFS console reports that the share must be manually removed. I believe this may have been caused by the shares/files being open by existing users (in this case its just templates and small files that aren’t mission critical.) Even though it reports this, I do see the DFS namespace gone from Active Directory (confirmed via ADSIEdit), the registry entries gone from the DFS key in the registry, yet on the server, when I try to delete the share from the folder I’m trying to move, it errors with “The share must be removed from Distributed File System before it can be deleted”.

Naturally I go down the path of doing some googling, and looking at blog posts talking about how to verify your DFS target was removed from active directory, from the file server registry, etc. This is all good practice anyway as it does verify things are cleaned up after a dirty removal of a namespace, but in my situation, the error still happened and I couldn’t un-share the old folder.

Simple answer: Reboot. In my case, after going down the AD and registry rabbit holes, I was able to restart the server service and let it restart any dependency services, and in doing so, it let me remove the share, re-share the new location, and create a new DFS namespace. I’d be willing to bet simply rebooting the server itself would have worked as well, but as we all know that’s not always an option when the workaholics are still plugging away at 7pm and I’m literally moving 15 files.

So definitely not a bad idea to check registry entries and AD objects when making DFS namespace changes, but start with a simple reboot, and get to go home 30 minutes sooner 🙂

IMAP Protocol in Office 365 bypasses MFA

Recently saw this article mention IMAP attacks against Office365 mailboxes due to IMAP bypassing MFA rules:

https://www.bleepingcomputer.com/news/security/multi-factor-auth-bypassed-in-office-365-and-g-suite-imap-attacks/

My suggestion is to bulk disable IMAP and POP of your organization doesn’t use them. You can use Powershell to disable these protocols en-bulk in seconds, however if your firm is larger, make sure those protocols aren’t in use first by various systems, especially IMAP.

You may also want to look at Activesync and OWA as well, not every mailbox likely needs those as well, especially system mailboxes.

Gets all IMAP enabled mailboxes
get-casmailbox | ? imapenabled -eq $true

Gets all IMAP enabled mailboxes and disables it

get-casmailbox | ? imapenabled -eq $true | set-casmailbox -imapenabled $false

Gets all POP enabled mailboxes

get-casmailbox | ? popenabled -eq $true

Gets all POP enabled mailboxes and disables it

get-casmailbox | ? popenabled -eq $true | set-casmailbox -popenabled $false

Edit: Heres another article about how to set defaults for the protocols. Remember to disable OWAforDevices if you don’t allow the Outlook IOS/Android app.

https://community.spiceworks.com/how_to/152329-setting-the-default-email-protocols-in-office-365

You can disable OWAforDevices for existing users using the same set-casmailbox cmdlet:

get-casmailbox | ? owafordevicesenabled -eq $true | set-casmailbox -OWAforDevicesEnabled $false