Monthly Archives: April 2009
Licensing your Exchange 2007 Edge Server
One of the new roles in Exchange 2007 is the Edge server role. The edge server is an Exchange server that sits in your DMZ and receives and sends SMTP mail to and from the Internet. It also performs a lot of other task like spam checking, anti-virus (if installed) etc. The Edge server is not a member of you Active Directory domain and uses an ADAM partition to hold the directory information it receives from an internal Hub/Transport server. The Edge server is present in Active Directory though, it is listed with the other servers under the Exchange Administrative Group (FYDIBOHF23SPDLT) in the configuration partition.
Whenever you install any Exchange 2007 server, before you enter a product key, each time you open the Exchange Management Console (EMC) you are reminded of the Exchange servers that still do not have a product key registered and are thus regarded by the EMC as trial servers. You can enter the product keys by using EMC or the Exchange Management Shell (EMS) which is PowerShell with some additions. I recently ran across an interesting problem trying to enter the product key for my Edge server.
After entering the product key for my combined Mailbox, Hub/Transport server and the CAS server; they disappeared from the warning displayed when I opened the EMC. But that still left me with the Edge server. First I tried entering the product key on the Edge server itself, that succeeded and the warning disappeared from the local EMC on the Edge server, but since there is no communication from the Edge server to the Hub/Transport server, only the other way, that did not help with the error displayed in the EMC on the internal servers. Next I tried using the EMS to set the key on the Edge server. The command is:
Set-ExchangeServer <servername> -ProductKey AAAAA-BBBBB-CCCCC-DDDDD-EEEEE
I then received this error:
Set-ExchangeServer : An error happened while accessing registry of the specified server: “<servername>”. The error message: “Attempted to perform an unauthorized operation.”.
At line:1 char:19
+ Set-ExchangeServer <<<< <servername> -ProductKey AAAAA-BBBBB-CCCCC-DDDDD-EEEEE
I guessed that the reason was that my domain administrator account was not allowed to update the registry on the Edge server, which made sense. (I did open port 445/TCP from the H/T server to the Edge server in the firewall, in addition to the ports required for ADAM sync.) I then tried running the cmdlet using runas in different ways, using the NETONLY option etc. If I ran runas with NETONLY I could access the Edge server, but then I lost access to the DC since the local account on the Edge server, which runas was using, did not have access to Active Directory. After pondering this duality for a while, the need to access the Active Directory and the registry on the Edge server at the same time over the network, using only one account I figured it out. How do you get “single-sign-on” in Windows across different security boundaries? You create duplicate accounts in each security boundary and give them the same password.
I created an account in the Edge Server’s security database (SAM) with the same name as my internal Domain Admins account and gave it the same password. Immediately the Set-ExchangeServer cmdlet succeeded and my Edge server was licensed in the eyes of Active Directory. No more warnings in the EMC.
I have installed a few Exchange 2007 servers now, but never had this problem before. That was also the reason it took me some time to figure this out; it had never been a problem before! I kept asking myself “Why doesn’t it work at this site, when it has worked so many times before?”. The reason was that on all the other sites I was already running with identical accounts on the internal network and on the Edge server. But this time the accounts were different.
Mismatched Email addresses causes recipients to be skipped during Offline Address Book generation
You might experience this error during an Offline Address Book generation cycle:
Index : 94460
EntryType : Warning
EventID : 9327
Message : OALGen skipped some entries in the offline address list ‘Global Address List’. To see which entries are affected, event logging for the OAL Generator must be set to at least medium.
– Default Offline Address List
Category : OAL Generator
CategoryNumber : 13
ReplacementStrings : {Global Address List, Default Offline Address List}
Source : MSExchangeSA
TimeGenerated : 03.01.2008 11:35:31
TimeWritten : 03.01.2008 11:35:31
UserName :
After you set the event log level for the OAL Generator to at least medium, eg. by using this EMS command:
Set-EventLogLevel ‘MSExchangeSAOAL Generator’ -level Medium
You start seeing these errors:
Index : 94454
EntryType : Error
EventID : 9325
Message : OALGen will skip user entry ‘user1’ in address list ‘Global Address List’ because the SMTP address ” is invalid.
– Default Offline Address List
Category : OAL Generator
CategoryNumber : 13
ReplacementStrings : {user1, Global Address List, , Default Offline Address List}
Source : MSExchangeSA
TimeGenerated : 03.01.2008 11:35:27
TimeWritten : 03.01.2008 11:35:27
UserName :
As we can see from the error in the Event Log, OAL Generator claims that the SMTP address ” (blank) is invalid. This is not surprising, as a blank address can not be used for anything.
I have discovered one reason for this error, there might be more. If the user’s primary SMTP address does not match the value in the mail attribute in Active Directory, this error is generated. This happens if you change the primary SMTP address in EMC. EMC does not update the address in the mail attribute. To see if you have any recipients in your organization that have a mismatch between these two values, run these EMS commands:
get-mailbox -resultsize unlimited | where { $_.WindowsEmailAddress -ne $_.PrimarySmtpAddress } | ft –auto
get-distributiongroup -resultsize unlimited | where { $_.WindowsEmailAddress -ne $_.PrimarySmtpAddress } | ft –auto
get-dynamicdistributiongroup -resultsize unlimited | where { $_.WindowsEmailAddress -ne $_.PrimarySmtpAddress } | ft –auto
This should be possible to do with Get-Recipient as well, but I cannot make it work. Get-Recipient always return every recipient in the organization.
To remedy this situation, these EMS commands may be of interest:
get-mailbox -resultsize unlimited | where { $_.WindowsEmailAddress -ne $_.PrimarySmtpAddress } | ForEach { Set-Mailbox $_ -WindowsEmailAddress $_.PrimarySMTPAddress }
get-distributiongroup -resultsize unlimited | where { $_.WindowsEmailAddress -ne $_.PrimarySmtpAddress } | ForEach { Set-distributiongroup $_ -WindowsEmailAddress $_.PrimarySMTPAddress}
get-dynamicdistributiongroup -resultsize unlimited | where { $_.WindowsEmailAddress -ne $_.PrimarySmtpAddress } | ForEach { Set-dynamicdistributiongroup $_ -WindowsEmailAddress $_.PrimarySMTPAddress}
You should probably test these commands with the –whatif parameter added to the Set cmdlets.
A good pointer as to which recipients have a mismatch between these values, are those recipients who no longer have their Email addresses updated by a recipient policy. You can quickly list which recipients are in this state:
get-mailbox -ResultSize unlimited | where { $_.EmailAddressPolicyEnabled -eq $false } | ft –auto
get-distributiongroup -ResultSize unlimited | where { $_.EmailAddressPolicyEnabled -eq $false } | ft –auto
get-dynamicdistributiongroup -ResultSize unlimited | where { $_.EmailAddressPolicyEnabled -eq $false } | ft –auto
Also recipients who are targets of E-Mail address policies (EAP), but where those policies have not been applied, are candidates for this error.
Lastly, you cannot set the mail attribute if a recipient is a target of an EAP.
Remember to set the Event Log level back to it’s original value after you have finished troubleshooting:
Set-EventLogLevel ‘MSExchangeSAOAL Generator’ -level lowest
What does the Protect object from accidental deletion setting in Windows Server 2008 Active Directory actually do?
Windows Server 2008 Active Directory introduced a setting called Protect object from accidental deletion on all directory objects:
This was implemented to avoid accidentally deleting objects from the directory. OUs have this setting set by default. But what does it actually do?
When this setting is set a Deny access control entry (ACE) is added to the security descriptor of the object (“DELETE” & “DELETE TREE”) and a Deny access control entry (ACE) is added to the security descriptor of the PARENT of the object (“DELETE CHILD”). The security principal associated with these ACEs is Everyone, and they apply to This object only.
So if we select to protect the OU company.com/Unit/Usersfrom deletion the following will happen in the directory:
- The UsersOU itself will get the “DELETE” and “DELETE TREE” DENY ACE set.
- The parent of Users, in this case the OU Unit, will get the “DELETE CHILD” DENY ACE set.
Quried with DSACLS.EXE this will look like this:
For the Users OU:
dsacls.exe “OU=Users,OU=Unit,DC=company,DC=com”
Owner: COMPANYDomain Admins
Group: COMPANYDomain Admins
Access list:
Deny Everyone SPECIAL ACCESS
DELETE
DELETE TREE
For the Unit OU (the parent of Users):
dsacls.exe “OU=Unit,DC=company,DC=com”
Owner: COMPANYDomain Admins
Group: COMPANYDomain Admins
Access list:
Deny Everyone SPECIAL ACCESS
DELETE
DELETE CHILD
DELETE TREE
If you want to set these ACEs yourself you can use DSACLS.EXE:
For the Users OU:
DSACLS “OU=Users,OU=Unit,DC=Company,DC=Com” /D “Everyone:SDDT”
For the Unit OU (the parent of Users):
DSACLS “OU=Unit,DC=Company,DC=Com” /D “Everyone:DC”
If your are still running Windows 2000 or Windows Server 2003, I highly recommend making this part of your standard steps for creating new OUs. You can also change the Active Directory Schema so that the ACEs are set by default when creating new objects. When I figure out how that is done I will update this post.
Using IIS 7 URL Rewrite Module to simplify Exchange 2007/2010 Outlook Web Access URLs on Windows Server 2008/2008 R2
The default URL for Outlook Web Access i Exchange Server 2007 is https://<server FQDN>/owa. This URL is always an issue for end users who find it too long or complex. They either forget to use HTTPS in front of the URL, or to append /owa to the server name, or both. The first mistake results in an error saying SSL is required. The second loads the root of the site. I agree that this could be made more user-friendly so I always implement some form of rewrite or redirection. Typically I make OWA available at just <server FQDN>. No HTTPS or subfolder, e.g. owa.company.com. This requires two things; redirecting HTTP traffic to HTTPS and redirecting the root folder to the /owa subfolder.
Note: The final URL for OWA is always (almost) https://<server FQDN>/owa. We cannot disable HTTPS or publish OWA at the root of the site. But the URL users type can be simplified. This simplification is what I mean when I say redirect in this article.
Until recently the redirection to HTTPS and the subfolder OWA could be accomplished by first redirecting the root folder with IIS 7’s HTTP redirect functionality and then editing the HTTP error page , typically 403, so that it would redirect to HTTPS instead of throwing an error. I have never liked this approach, especially the latter part. You could also use ISA Server 2006 in front of your Exchange server and do the same there. But recently a much better solution has arrived. The IIS team has released the URL Rewrite Module extension to IIS 7 which lets you perform advanced URL rewrites and redirects using, among other things, regular expressions.
How to simplify the OWA URL with URL Rewrite:
- Download and install the URL Rewrite extension on your CAS server.
http://www.iis.net/extensions/URLRewrite
Remember to get the version for your architecture. This will almost always be x64 unless you are in a lab and running the x86 version of Exchange 2007.
To avoid having to restart your server follow the steps in this post:
http://forums.iis.net/t/1153276.aspx
Also, these instructions are written for the 2.0 version. I cannot guarantee that they will work with any older or newer version. - Disable the Require SSL setting on the Default Web Site.
This is necessary for the redirection in URL Rewrite to work. This is not a security issue since URL Rewrite will force SSL for the entire site (except for OAB).
- Open the web.config file under your wwwroot folder.
This is usually under %systemdrive%inetpubwwwroot.
The web.config file does not exist by default, so change a setting on your site and change it back again to have IIS generate the file. - Paste the following text in web.config in the <system.webserver> section:
https://gist.github.com/morgansimonsen/8040092
NOTE: The PowerShell vdir entry is to exempt the /powershell virtual directory found on Exchange 2010 Servers from HTTPS enforcement. This is necessary for remote management of Exchange 2010 Client Access Servers. This rule should have no bearing on an Exchange 2007 server as they do not have the powershell vdir.
This will create three new rewrite rules.
Rule name | Function | Notes |
Redirect root | Redirects the root folder to /owa | |
Exempt OAB from SSL | Turns off the requirement for SSL for the /OAB subfolder. This is the default Exchange 2007/2010 setting. If you want to have SSL for the OAB folder as well, delete this rule and update the OAB URL setting in Exchange. |
Stop processing enabled |
Exempt PowerShell vdir from SSL | This rule is only required for Exchange 2010, but can safely be imported on Exchange 2007. | Stop processing enabled |
Force HTTPS | Enforces HTTPS for all requests to the site. |
- Perform a test
All requests for the root folder or for the /owa folder missing SSL will now be redirected to the OWA logon page. All other subfolders are not redirected, except to enforce SSL, and can be accessed directly.
Note: The Exchange 2007/2010 web folders usually inherit their SSL settings from the Default Web Site, so when you turn off the SSL requirement for the site you also turn it off for the web folders. If, for some reason, any of the subfolders manage the SSL setting in their own context (ie. they do not inherit the SSL setting from the site level) you have to disable Require SSL for those folders as well. If not, the URL Rewrite will not kick in and you will get an error instead of a redirect. The folders associated with Exchange 2007/2010 are:
- Autodiscover
- EWS
- ecp
- Exchange
- Exchweb
- Microsoft-Server-ActiveSync
- OAB
- Owa
- Public
- Rpc
- RpcWithCert
- UnifiedMessaging
All these should have their Require SSL Setting turned off. For any other folders you may have on the server you will have to decide for yourself if you want them to be included in the URL Rewrite SSL Enforce or manage their SSL settings individually. Also make sure to check any other folders that should have SSL active still has that setting set when you deactivate the requirement for the site.
I find this solution to simplifying the URL for OWA to be much more streamlined and elegant than any previous solution. The URL Rewrite filer is a module developed by Microsoft meaning it has been through the Secure Development Lifecycle (SDL). You have only one place to make all changes. You do not have to make changes to the default IIS configuration (ie. editing or changing the error pages).
Morgan
Update: When you disable the Require SSL setting in IIS you rely on URL Rewrite to perform the enforcement for SSL on your sites and directories. I have been in contact with the author of URL Rewrite, asking him if this configuration is a security risk and if the enforcement of SSL through URL Rewrite is as strong as the one in IIS. His reply was that it was not but that this was a cause for concern in very few situations. You have been warned.