29 January 2014

Get active OWA sessions by email

Sometimes you have to know how many users are connected to your Outlook Web App.

I brew up some script to show you just that:

# Script: Get-OWASessions.ps1
# Purpose: Shows the users currently connected to OWA
# Author: Edwin van Brenk
# Date: 28-01-2014
# For:         Company

#Functions
$filename = "D:\Temp\OWASessions.html"
$date = get-date -Format dd-MM-yyyy 
$smtpServer = "smtp.company.lan"
$smtpFrom = "OWASessions@company.com"
$smtpTo = "username@company.com"
$messageSubject = "Active OWA Sessions $date"

Write-Host "Deleting temp file"
#If outputfile already exsists then delete
if (Test-Path($filename))
{
remove-item $filename
}

write-host "Getting OWA sessions please wait"
$htmlreport = Get-Mailbox -resultsize unlimited | Get-LogonStatistics | Where-Object {$_.ApplicationID -eq "Client=OWA"} | Select-Object UserName,LastAccessTime | ConvertTo-Html
Write-host "Creating output file"
$htmlreport | Out-File $filename
write-host "Getting ready to send the email"
$message = New-Object System.Net.Mail.MailMessage $smtpfrom, $smtpto
$message.Subject = $messageSubject
$message.IsBodyHTML = $true

$message.Body = ( $htmlreport | out-string )
$message.Body = $htmlreport
write-host "Sending email"
$smtp = New-Object Net.Mail.SmtpClient($smtpServer)
$smtp.Send($message)

Write-Host "Done"

23 January 2014

Disabled Accounts and ActiveSync Devices Continuing to Sync

Came across this article wich shed's some light on why users can keep on sending and receiving email when their password is expired or the whole useraccount is disabled.

This means that when a user leaves your company, disabeling the useraccount just doesn't cut it.

Disabled Accounts and ActiveSync Devices Continuing to Sync


Recently, an issue that has been around for some time started generating a lot of renewed interest.  The issue I'm referring to is regarding Exchange users still having access for several hours after their AD Account has been disabled.  This post is Part I of II, discussing why this happens and best practices to properly deal with/cut off access to users as quickly as possible relating to ActiveSync.  In Part II, I  will discuss this issue as it relates to Outlook and OWA and the best practices on how to deal with them
The main issue of concern is that if a user is terminated and just their AD account is disabled (which is a fairly standard process for many companies), that once their AD account is disabled it’s believed that the user is now stopped from being able to access anything using Windows Authentication, such as Exchange).  However, that may not necessarily be true…especially with ActiveSync.  If we’re talking about a terminated employee who was “walked out the door” and you want to IMMEDIATELY stop them from being able to send/receive emails via an ActiveSync device and all you've done is disable their AD account, they may still be able to sync for some time and send emails that you don't want sent.  This can then open a whole slew of headaches.

Why Does This Happen?

The ability for ActiveSync to continue to work even though the user's AD Account has been disabled is because of several reasons.  One of the main reasons is due to the way ActiveSync keeps a connection open to the server to watch for new messages.  That connection has already authenticated and has been validated…so while the AD count may be disabled, all Exchange knows is that the user HAD rights to the mailbox and is continuing to use that connection.  Eventually, the “life” of that authentication expires and the user has to re-authenticate (which is all done transparent to the user) and if the account was disabled, the re-authentication will fail and the user will no longer be able to sync.  ActiveSync devices with their long heartbeat intervals and token cache can still allow access up to 24 hours after an AD account has been disabled.  This is also related to caching done by IIS and Exchange, which I will talk about more in Part II.  But, in summary, just disabling a user's AD account will likely not stop them from accessing Exchange for at least a couple of hours if not more.

Best Practices to Follow Regarding Disabling User Access

  1. Before disabling the AD Account, you should do the following:
a. Trigger a remote wipe of the device - OPTIONAL
This may or may not be something you want to do depending on your company’s policies, if it’s a personal device, etc.  However, once the sync is stopped through other means the device cannot come in and get the Wipe Request, so this is one of the first things that should be done if your company deems it necessary.
b. In addition, implement a block of all their devices (if you didn't issue a remote wipe and/or their device doesn't support remote wipe, etc):
If using Exchange 2010/Office365:
Get information about the user and devices
Get-CASMailbox <user> | Select ActiveSyncAllowedDeviceIDs, ActiveSyncBlockedDeviceIDs
Get-ActiveSyncDeviceStatistics –Mailbox <user> | fl DeviceID
Block all Devices for a user
Set-CASMailbox -Identity <user> -ActiveSyncBlockedDeviceIDs "<DeviceID_1>,<DeviceID_2>"
If using Exchange 2007:
Get information about the user and devices
Get-CASMailbox <user> | Select ActiveSyncAllowedDeviceIDs
Get-ActiveSyncDeviceStatistics –Mailbox <user> | fl DeviceID
Block all Devices for a user
Set-CASMailbox -Identity <user> -ActiveSyncAllowedDeviceIDs "BLOCKED"
(Note: The use of the string “BLOCKED” is to enter a string that does NOT match any device they may be using as setting this value will ONLY allow a device with that Device ID string to sync [which no real device would have the Device ID of “BLOCKED”] and all others to NOT be allowed to sync)
c. Disable ActiveSync:
Set-CASMailbox -Identity <user> -ActiveSyncEnabled $false
d. Disable the mailbox (at least temporarily) - OPTIONAL
Note: It’s understood that some companies leave the mailboxes enabled to receive email so that OOF/automatic responses can be generated or so that no emails to the address are not blocked.  If this is the case, it’s recommended that you disable the mailbox for approximately 30m-1h and then enable again.  This will allow time for the change to go into effect and stop allowing ActiveSync to access.  This solution is in lieu of ActiveSync disabling as outlined above.
2. Disable the AD account.

Do note, the above changes are NOT instantaneous!  It can take around 5-10 minutes for the ActiveSync device blocking to go into effect, and that’s from the time that the change is replicated to all the DC/GCs used.  Obviously, if you make the changes against a DC/GC in another site and it has to replicate to the Internet-facing Exchange site(s) more time is needed.  The other settings can take up to 20 minutes to go into effect due to caching.
You may ask why we recommend using –ActiveSyncBlockedDeviceIDs AND –ActiveSyncEnabled?  It’s because the check for ActiveSyncBlockedDeviceIDs is checked almost continuously, since that part of Exchange is designed around the premise that devices are added or removed regularly.  However, ActiveSyncEnabled’s setting is cached for up to 20 minutes and then may only be rechecked if IIS Token Caching has expired.


Best Practices to Follow Regarding Disabling User Access

Here are the best practices related to Outlook and OWA:
  1. Before disabling the AD Account, you should do the following:
    1. Disable Web services for the mailbox:
For Exchange 2007:
Set-CASMailbox -Identity <user> -OwaEnabled $false
 For Exchange 2010:
Set-CASMailbox -Identity <user> -OwaEnabled $false
Set-CASMailbox -Identity <user> -EwsEnabled $false
Set-CASMailbox -Identity <user> -EwsEnabled $false
Set-CASMailbox -Identity <user> -EcpEnabled $false
  1. Disable MAPI services:
For Exchange 2007:
Set-CASMailbox -Identity <user> -MapiEnabled $false
Set-CASMailbox -Identity <user> -MapiBlockOutlookRpcHttp $true
For Exchange 2010:
Set-CASMailbox -Identity <user> -MapiEnabled $false
Set-CASMailbox -Identity <user> -MapiBlockOutlookRpcHttp $true
Set-CASMailbox -Identity <user> -EwsAllowMacOutlook $false
Set-CASMailbox -Identity <user> -EwsAllowOutlook $false
  1. Set Recipient Limits to 0
Set-Mailbox -Identity <user> -RecipientLimits 0
  1. Disable the mailbox (at least temporarily) - OPTIONAL
Note: It’s understood that some companies leave the mailboxes enabled to receive email so that OOF/automatic responses can be generated or so that no emails to the address are not blocked.  If this is the case, it’s recommended that you disable the mailbox for approximately 30m-1h and then enable again.  This will allow time for the change to go into effect and stop allowing clients to access.  This solution is in lieu of disabling as outlined above.
  1. Disable the AD account


Source:
Part 1
Part 2

12 January 2014

After Exchange 2010 SP3 RU4 OWA & Active Sync are messed up

After installing Exchange 2010 SP3 RU4, webmail and Active sync stopped working.
External access to our webmail page was impossible.

Turns out that the update had made some configuration changes for us, THANKS!!! not
The hardware load balancer in our environment does SSL offloading.
So the SSL options in IIS are turned off.

The RU4 update however thought it was a good idea to turn on SSL for the default web site on both CAS-HUB servers. Result, no way to get in to the webmail and get active sync to work.

Turn the SSL off and a few minutes later we were good to go.

Once again, spank you Microsoft for undocumented features and making my free sunday even shorter.

A well back to the last 2 servers that need to be updated, I got some errors in those too, so I think in about an hour or so there will be another rant from me.

After Exchange 2010 SP3 OWA is messed up

After installing SP3 for Exchange 2010 the Outlook webapp stopped working.

Outlook Web App didn't initialize. If the problem continues, please contact your helpdesk.
Couldn't find a base theme (folder name=base).
After some digging I found out that the default theme folder for OWA was empty.
So tried to copy the entire OWA directory from a working CAS-HUB server and pasting it over the empty one.
File copy error's, warning's, what the fcuk are you doing, no go....
So some more digging, and came up with updatecas.ps1.
After running this on the faulty CAS-HUB server al is well:
[PS] C:\Program Files\microsoft\Exchange Server\V14\Bin>.\UpdateCas.ps1
[14:54:52] ***********************************************
[14:54:52] * UpdateCas.ps1: 24.12.2010 14:54:52
Creating a new session for implicit remoting of "Get-ExchangeServer" command...
[14:55:06] Updating OWA/ECP on server "E.server2010"
[14:55:06] Finding ClientAccess role install path on the filesystem
[14:55:07] Updating OWA to version 14.1.270.1
[14:55:07] Copying files from 'C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\owa\Current' to 'C:\Program
Files\Microsoft\Exchange Server\V14\ClientAccess\owa\14.1.270.1'
[14:55:24] Found 1 OWA virtual directories.
[14:55:24] Updating OWA virtual directories
[14:55:24] Processing virtual directory with metabase path 'IIS://"E.server2010".domain.com/W3SVC/1/ROOT/owa'.
[14:55:24] Creating metabase entry IIS://"E.server2010".domain.com/W3SVC/1/ROOT/owa/14.1.270.1.
[14:55:24] Configuring metabase entry 'IIS://"E.server2010".domain.com/W3SVC/1/ROOT/owa/14.1.270.1'.
[14:55:24] Saving changes to 'IIS://"E.server2010".domain.com/W3SVC/1/ROOT/owa/14.1.270.1'
[14:55:25] Saving changes to 'IIS://"E.server2010".domain.com/W3SVC/1/ROOT/owa'
[14:55:25] Update OWA done.
[14:55:25] Updating ECP to version 14.1.270.1
[14:55:25] Copying files from 'C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\ecp\Current' to 'C:\Program
Files\Microsoft\Exchange Server\V14\ClientAccess\ecp\14.1.270.1'
[14:55:27] Update ECP done.
 
Now great news, but on the other hand, why does Microsoft even have this option in the default installation for Exchange? It doesn't show much faith in their own products, or is it just me rambling on about my own frustrations and another Sunday down the drain by doing scheduled maintenance in the weekends....
As we say in the Netherlands: Dan had je maar een vak moeten leren! Than you should have studied a skill! (I think something gets lost in translation....:-)