UC Unleashed

Dealing with spam is like herding cats. It moves in every direction, and just when you think you might have it corralled, something comes along in a completely different direction.

Exchange has some fabulous features for reducing the amount of spam that lands in end-user mailboxes, and those features are well documented. Sometimes, you just want to see what’s being stopped. That’s where today’s one liner comes in. This little tidbit will troll through the tracking logs of the server you run it on, and display the failed messages from the last 7 days – most of which are stopped by the Content Filtering Agent. Of course, you can change the number of days to look back, as larger environments will no doubt have a tremendous number of failed messages. Here we see the sender’s email address, recipients, message subject, and the time stamp when the message was attempted.

Get-MessageTrackingLog -ResultSize unlimited -Start ((Get-Date).AddDays(-7)) | Where-Object {$_.EventId -eq "fail"} | Select-Object Sender,Recipients,MessageSubject,TimeStamp

We can specify a specific server to search on:

Get-MessageTrackingLog -ResultSize unlimited -Server  -Start ((Get-Date).AddDays(-7)) | Where-Object {$_.EventId -eq "fail"} | Select-Object Sender,Recipients,MessageSubject,TimeStamp

Or, search all servers:

Get-TransportServer | Get-MessageTrackingLog -ResultSize unlimited -Start ((Get-Date).AddDays(-7)) | Where-Object {$_.EventId -eq "fail"} | Select-Object Sender,Recipients,MessageSubject,TimeStamp

And, we can also dump the data to a .csv file for manipulation:

Get-MessageTrackingLog -ResultSize unlimited -Start ((Get-Date).AddDays(-7)) | Where-Object {$_.EventId -eq "fail"} | Select-Object Sender,Recipients,MessageSubject,TimeStamp | Export-Csv c:\failedmessages.csv

Enjoy!

During a recent power “issue”, I had to restart an entire rack full of Hyper-V servers. While an Exchange VM was booting, a networking issue caused the VM to not be able to connect to anything else, including domain controllers. As a result, many services couldn’t start. Rather than bouncing the server, or manually starting the services, this little one liner came in handy. Unfortunately, Get-Service doesn’t expose the startmode. That would make it too easy. So, we use Get-WMIObject:

Get-WMIObject win32_service | Where-Object {$_.name -match "exchange" -and $_.startmode -eq "Auto" -and $_.state -ne "running"} | Start-Service

Of course, we can remove the name check and look for all services on the server that should be (but aren’t) started, and start them:

Get-WMIObject win32_service | Where-Object {$_.startmode -eq "Auto" -and $_.state -ne "running"} | Start-Service

Ståle Hansen has reminded me that in Lync, there is also another solution:

Get-CsWindowsService -ExcludeActivityLevel | Where-Object {$_.Status -like "Stopped"} | Start-CsWindowsService

Sometimes while implementing new corporate policies, such as those that control forwarding messages outside of an environment, an admin needs to figure out who is configured that way. This can be a daunting task to go down through every account, visually inspecting each. PowerShell comes to the rescue in this one liner:

Get-Mailbox -ResultSize Unlimited | Where-Object {$_.ForwardingAddress -ne $null} | Select-Object Name, @{Expression={$_.ForwardingAddress};Label="Forwarded to"}, @{Expression={$_.DeliverToMailboxAndForward};Label="Mailbox & Forward"}

As we see in our test, one user, Robert Sweet, is configured for forwarding. His account forwards to a contact called “Robert Sweet [External]”, and based on the Mailbox & Forward being False, we know that it only forwards to the external address, and does not also deliver to the Exchange mailbox.

If we needed to, we could use

Get-Contact "Robert Sweet [External]" | Format-List

to get info about the contact, including the destination SMTP address. If we need to disable forwarding for all of the enabled users, we can use

Get-Mailbox -Resultsize Unlimited | Where-Object {$_.ForwardingAddress -ne $null} | Set-Mailbox -ForwardingAddress $null

This comes up pretty often, especially around migrations and upgrades, or after some embarrassing incident. A manager wants to have a report of users who have send-as rights to other mailboxes. Fortunately, we can use PowerShell to do the heavy lifting:

Get-Mailbox -ResultSize Unlimited | Get-ADPermission | Where-Object {($_.ExtendedRights -like "*send-as*") -and -not ($_.User -like "nt authority\self")} | Format-Table Identity, User -auto

This gives us a nice list of those users. As we see, user msweet has send-as permissions to Timothy Gaines’ mailbox:

To find users who have Full Access to the mailbox of others, we can use:

Get-Mailbox -ResultSize Unlimited | Get-MailboxPermission | Where-Object {($_.AccessRights -match "FullAccess") -and -not ($_.User -like "NT AUTHORITY\SELF")} | Format-Table Identity, User

And we see that the same msweet has full control to the mailbox of user Oz Fox

In each example, we can replace the Get-Mailbox -ResultSize unlimited with a narrower scope, such as Get-Mailbox to look at specific accounts.

Note that in bigger environments, it can take quite a bit of time for this to run.

Fellow MVP Jeff Guillet wrote an article about the fact that disabling a user’s Active Directory account doesn’t mean they can’t log into Lync/Skype for Business. This is due to the way Lync uses certificates and authentication based on them. I highly recommend you read the article.

I recently was writing some documentation for a customer and wanted to include this important information, including methods for resolving the problem after the fact.

If you’ve not been disabling users in Lync while disabling them in AD, here’s a one liner to find those users:

Get-CsAdUser -ResultSize Unlimited | Where-Object {$_.UserAccountControl -match "AccountDisabled" -and $_.Enabled -eq $true} | Format-Table Name,Enabled,SipAddress -auto

You can shorten it somewhat by not checking if $_.Enabled is $true, but just that it exists. You can get a count of the users using:

Get-CsAdUser -ResultSize Unlimited | Where-Object {$_.UserAccountControl -match "AccountDisabled" -and $_.Enabled} | Measure-Object

and, if you want, can disable them in one line using

Get-CsAdUser -ResultSize Unlimited | Where-Object {$_.UserAccountControl -match "AccountDisabled" -and $_.Enabled} | Disable-CsUser

Update 09-14-2012: Be careful using that last option if you’ve configured test accounts for synthetic testing using the New-CsHealthMonitoringConfiguration cmdlet as I mention in Lync Synthetic Tests: What They are and When They Don’t Work – Part I.

Update 04-12-2014: Replaced aliases with full cmdlet per best practices.

Update 09-19-2014: Added -ResultSize Unlimited

Anyone who’s had a new mailbox on Exchange 2007 and logged in via OWA will remember seeing a screen that asks for the language and time zone, as seen below. Once they pick those, they are then taken to their mailbox.

If all of the users in an org use the same language and are in the same time zone, we can set these settings. New users will no longer be prompted for this information, but any user can change the information by going to to Options>Regional Settings in OWA, such as shown below:

To make the change, fire up the ol’ Exchange Management Shell and type:

Set-OWAVirtualDirectory "owa (Default Web Site)" -DefaultClientLanguage <Locale ID>

Replace <Local ID> with the specific Local ID for your area. For a list of Local IDs, see Locale IDs Assigned by Microsoft. For English in the United States, the Local ID is 1033. So, for my example, I use

Set-OWAVirtualDirectory "owa (Default Web Site)" -DefaultClientLanguage 1033

Once that’s set, all new users will default to that, as well as the time zone setting on the client access server.

At least three times in the past couple of weeks, I’ve been asked how to dump the members of a DL to Excel for reporting.

Fortunately, it’s a very simple task using two PowerShell cmdlets, Get-DistributionGroupMember and Export-Csv.

Remember than in PowerShell, we can pipe the results of one command as input into another. So first, we get the membership of a list, then we send it to the CSV file for Excel. What we wind up with is:

Get-DistributionGroupMember -Identity "testdl" | Export-Csv -Path "C:\MyFile.Csv"

Where testdl is our distribution group, and myfile.csv is the resulting CSV file.

We can clean that up a little by using the -NoTypeInformation switch during the export-csv cmdlet so that we don’t get the top line of type information.

Get-DistributionGroupMember -Identity "testdl" | Export-Csv -Path "C:\MyFile.Csv" -NoTypeInformation

That gives us a nice clean CSV file that we can then further manipulate as needed in Excel.

If you’d like to learn a lot more about PowerShell and Exchange 2007, check out Professional Windows PowerShell for Exchange Server 2007 SP1 from Wrox. It’s a great reference book.