ExchangeNerd

Powered by Ed Buford and Coffee

Archives: June 2015

Clean that Database!

Clean Database command missing in Exchange 2013

Sometimes you need to disable a mailbox you need to be able to see it as a disconnected mailbox right away. In the Past you’ve been able to use the Clean-Mailboxdatabase command.  I would normally tend to run the clean command against all databases since the command doesn’t draw much in the way of resources. So for me the command would look like this:    Get-Mailboxdatabase | Clean-Mailboxdatabase

But as with everything the times are constantly changing and so are the commandlets that go with them. Which brings me to Exchange 2013 where the Clean-Mailboxdatabase command no longer works. Now the command is Update-StoreMailboxState and sadly it’s not a simple command to clean all the databases – in fact to run the command you need to know the database and mailbox GUID. Now this is going far… but I digress…

Anyway if you know the database you can attack it like this:

Get-MailboxStatistics –Database DB01 | ForEach { Update-StoreMailboxState -Database $_.Database -Identity $_.MailboxGuid -Confirm:$false }

 

GetMailboxStatistics Database MDB02 |ForEach { UpdateStoreMailboxState Database $_.Database Identity $_.MailboxGuid Confirm:$false }

Finding AD Groups with PowerShell

How to List AD Groups by type using PowerShell

The AD group type is a bit of a mystery to me. I’m not sure why Microsoft has chosen to make thing they way they have and I have to keep reminding myself they have been building Active Directory a lot longer than they have been building PowerShell.
Today one of my team asked me to see if I could pull Domain Local groups out of AD using PowerShell. I was sure this was going to be as easy as it sounds. Turns out it isn’t straight forward.

Since there isn’t a Get-ADGroupType PowerShell command I went looking at the Attributes and here’s what I found:

2015-06-08_14h57_36

Even more confusing when you Open that Attribute you get something even more interesting:

2015-06-08_14h58_48

 

So I started searching around MSDN and I came up with this chart:

Group Type                                                 Value
Global distribution group                        2
Domain local distribution group           4
Universal distribution group                  8
Global security group                               -2147483646
Domain local security group                  -2147483644
Universal security group                         -2147483640

Now that I have the value I’m looking for I can pull it out of AD:
In order to do that I need to log into Domain Controller or a Domain computer with RSAT loaded.  Then I can import the ActiveDirectory module:

Import-module ActiveDirectory

Then I can get the Group Type by using the command below

Get-ADGroup -Filter * -Properties GroupType | where {$_.GroupType -eq “-2147483644”} | FL name

If I want to change the Group Type that I’m searching for then I just change the number from the list above make sure to include the Negative on the ones that have it listed.

[sourcecode language='powershell' ]
Get-ADGroup -Filter * -Properties GroupType | where {$_.GroupType -eq "-2147483644"} | FL name

[/sourcecode]
[Top]

It’s Midnight, Do you know where your FSW is?

Your FSW is more important than you may think!

Over the past couple of weeks I’ve seen two Database Availability Groups that had their File Share Witness go missing on them. In both cases the server which housed the FSW were replaced and the FSW role was not recreated.

I’m guessing you’re asking yourself “how that can ever happened?” The truth is it’s a lot easier than you think. With a 2 node cluster and File Share Witness you only need 2 nodes up to have a Quorum. This means if both of your DAG servers are up good, or if one DAG server a and the FSW is up you’re still good. The problem is that a well configured Exchange server is kind of “Set it and Forget it” and losing a FSW can have no impact on you at all when the Servers are both up. However when one of your servers go offline for whatever reason, the remaining server relies on the FSW to hold a quorum. IF you don’t have enough nodes to maintain a Quorum then all your Database will DISMOUNT!

This action is by design, there is a crazy thing that could happen to you called Split Brain where you would write different data to your 2 copies of the database that leaving it out of sync. Since you don’t that to happen you need the  FSW.  The FSW is a great thing that should not be forgotten!

One way to tell if your FSW is online is to use the Fail Over Clusters powershell tools. You can do that from your Exchange Server. I always do it from the Standard PowerShell console (I don’t know why) but the module will load into your EMS as well.

Import-Module FailOverClusters

Get-ClusterResource

Depending on your status the output should look like one of these:

2015-06-01_16h03_33

Or you could create a task to in your event log to email you if this error shows up in your Event Logs

2015-06-01_15h54_17

Here’s a link on how to do that: https://technet.microsoft.com/en-us/library/cc732728.aspx

[Top]