Why you shouldn’t put an Exchange Server in the DMZ

The official Microsoft documentation for Exchange Server is contradictory in terms of deploying an Exchange Server into your perimeter network (DMZ). In many cases, it is interpreted that placing an Exchange Server into this zone is a good idea.

This is a myth.

As a standard rule of managing your network, you should never place any machine joined to the domain into the DMZ. Exchange 2000, 2003 and 2007 (with the exception of the Edge Transport role – see below) must all be installed on machines joined to the domain – place them into the DMZ and you break the first rule of firewalls and Active Directory, which I mentioned above.

So why is this a bad idea?

An Exchange Server needs Active Directory to function because most of its configuration information is stored in the directory service. This is the reason why it must be deployed on a domain-joined server.

If you attempt to move an Exchange Server to the DMZ, you will quickly find that Exchange will break. This is because it loses the ability to find and communicate with the Domain Controllers on the private network. In situations like this, you would have to do one of two things:

• Deploy an additional Domain Controller into the DMZ
• Allow the Exchange Server access to the DCs on the private network

Completing either of the above tasks requires you to open ports between the DMZ and private network. The list of ports is extensive and includes sensitive services such as DNS, LDAP and NetBIOS. I heard a fellow Exchange Server MVP state the other day while referring to this list of ports: “open these ports and your firewall rules will look like Swiss Cheese”.

The bottom line is this defeats the principle of a DMZ. A DMZ is intended as a ’safe’ location for machines which are not joined to the domain; you might put public web servers or public nameservers there, for example. In the DMZ, they are protected from the Internet, but anyone maliciously gaining access to those servers cannot cross the firewall into your private network. By opening the Active Directory ports I describe above and by placing a domain-joined machine in this insecure zone, any hacker in control of a compromised machine in the DMZ has a much easier route to access your Active Directory environment, perhaps bringing it to its knees.

Every Exchange MVP I know considers this to be a very, very bad idea. They would not configure an Exchange Server in this way and neither would I.

Any Exchange Server you deploy should always be on the private network. Located there, you can ensure it has access to the Domain Controllers without the need to compromise network security. From the outside, you only ever need ports 25 and 443 open to allow internal email to flow and for users to access Outlook Web Access and Exchange ActiveSync.

But what about Exchange 2000/2003 Front End Servers?

What about them? Again, it is a misconception – probably brought about by ambiguous documentation – that leads people to believe these servers are there for security reasons. They are not. Legacy Front-End Servers are designed for organisations with multiple mailbox servers. A front-end acts as a central connection point for access to OWA, OMA or ActiveSync under a single, common URL – it does not provide security.

If you are deploying a front-end server because you believe it will secure your Exchange environment, think again. Install Vamsoft ORF on a Virtual Machine or use an external spam filtering service as an alternative.

Exchange 2007 Edge Transport

With Exchange 2007, Microsoft have recognised this problem by adding the Edge Transport server role. This is the first time an Exchange Server role has been specifically designed to be located on the perimeter network. It is also the first time such a role exists for security reasons. The Edge Transport machine is designed to be on a workgroup – not a member of the domain – so it does not require sensitive ports to be opened between the DMZ and private network. It maintains its own copy of the Active Directory database using Active Directory Application Mode (ADAM) in Server 2003 or Active Directory Light-Weight Directory Services (AD LDS) in Server 2008.

I personally do not see a requirement for an Edge Transport server in an Exchange deployment, so I never deploy them. They are an unnecessary expenditure. Unlike a 2000/2003 front-end, they only process SMTP email traffic. Requests for OWA or Exchange Activesync still need to be made directly to the Client Access Servers (CAS), which are domain members and therefore still need to be located on the private network.

The minimal security advantage Edge Transport servers provide can easily be achieved directly on the Hub Transport servers – or by deploying a much cheaper Vamsoft ORF virtual server between the Internet and the Hub Transport server.

Conclusion

You should now have a better understanding of why an Exchange Server should not be deployed into the DMZ. I hope this prompts you to review your Exchange configuration and make appropriate changes to further improve your network security.

Illegal breakage found in headernever

Active Directory Diagnostic Logging

Active Directory MVP Brian Desmond just posted a great blog entry which describes the generic registry settings he makes on a new Domain Controller.

The ones which are particularly important for any Domain Admin are the diagnostic logging settings for the Active Directory services. Any dedicated admin should keep a watchful eye on their DCs and know exactly what is going on with them. Making effective use of Diagnostic Logging is one of the best ways you can do this. By default, only errors are logged by Active Directory, something which isn’t useful for day-to-day monitoring and administration.

In the above linked blog post, Brian adds a line to ensure Active Directory logs the white space available in the database (also known as ‘the DIT file’ – from NTDS.DIT) after Garbage Collection does its work and removes objects permanently from the database. For any Exchange Server admin, you will be familiar with the concept of white space in the databases. The Active Directory DIT file uses the ESE storage engine in the same way as Exchange does, meaning white space is also left in the Active Directory database as objects are removed.

There are a few Microsoft support sites which explain all the diagnostic logging settings (there are several) in more detail, how to enable each setting and set the logging level. I’d suggest you take a look at this one to begin with: http://technet.microsoft.com/en-us/library/cc961809.aspx.

Happy Diagnostic Logging!

Configuring Windows Time for Active Directory

I’ve had a few requests recently from people who were confused regarding how to configure time in their Active Directory domains – and some were playing with settings on servers and workstations to try to make things work. In this article, I’ll briefly explain how the time service works in Active Directory networks and general information on how you should go about configuring it.

For anyone not aware, all machines in an Active Directory environment automatically find a time server to sync time with. Workstations use their authenticating Domain Controller, and the DCs sync with the server holding the PDC Emulator FSMO role. In a multi-domain forest, the PDC Emulator in each child domain synchronises with a DC or the PDCe in the forest root domain. To ensure the time remains reliable across the forest, only the PDC Emulator in the forest root domain should ever sync with an external time source – this leads to only one source of time being used across the forest. The Windows Time Service blog have a great post entitled Keeping the domain on time which explains this in more detail, including a great graphic.

The Windows Time Settings

You can find the settings for the Time Service in the registry, under HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters. The most important value to note is the ‘Type’ string – on any domain machine other than the PDC Emulator in the forest root, this should be set to NT5DS. That name isn’t particularly descriptive; if it is set, it means the machine is finding a time server in the Active Directory hierarchy.

If it isn’t set to that, you should think about resetting the time service on that machine. To do that, run a Command Prompt as an Administrator and execute the following commands:

net stop w32time
w32tm /unregister
w32tm /register
net start w32time

Check the registry again, and the Type should now be in domain sync mode (NT5DS).

Sometimes, you may find an NTPServer key in the registry despite the Type being set to NT5DS. NT5DS doesn’t use an NTP Server, so what gives? This setting is simply left over from prior to the machine being joined to the domain, when it was in a workgroup. Provided the Type value is set correctly, the NTPServer entry can be completely ignored or even deleted. Running the above commands on a domain-joined machine will delete it automatically.

The Group Policy Settings

There are also a number of Group Policy settings for the time service. These can be found in Computer Configuration\Administrative Templates\System\Windows Time Service.

I do not encourage you to change these settings; if you have done so, you probably want to revert the policies to ‘Not Configured’. There are reasons why you may make the odd change, but in general, no changes are required and you can actually break the time sync if you do make them.

If you are interested in reading further about what they do, the Windows Time Service blog has another great page going through them: Group Policy Settings Explained.

The Forest Root PDC Emulator Settings

After a bit of a configuration reset, all your DCs, member servers and workstations should now be set to sync from the domain hierarchy. But what about the PDC Emulator in the forest root?

The fact of the matter is the PDCe doesn’t actually need to synchronise with anything. It automatically designates itself the most reliable time server in the domain and it can run quite happily like that, without ever talking to an external time server. My earlier blog post entitled Time: Reliable or accurate? describes why.

However, to have an easy life and keep your users from complaining, it is almost always a good idea to have some form of external time sync on the forest root PDC Emulator. There are a number of ways to do this – for example, an external hardware clock which syncs with GPS. However, the most common (and cheapest – free) solution is synchronising with another NTP server on the Internet. I use the servers closest to me which participate in possibly the largest time service, the NTP Project (list of time servers).

To configure the time sync on the PDCe, you need to execute the following commands. I’d strongly suggest you get a level playing field by resetting the time service using the instructions above before you start.

w32tm /config /manualpeerlist:”uk.pool.ntp.org,0×8 europe.pool.ntp.org,0×8″ /syncfromflags:MANUAL /reliable:yes /update

What’s that command doing?

That command is a rather hefty command, so you may like to know exactly what it is doing to your server. All the changes are taking place in the registry at the key I posted above; using the w32tm tool to make the configuration changes is simply much easier than doing it manually yourself.

/config causes the tool to enter configuration mode. There are a number of other modes it supports which you can find by running w32tm /?.

/manualpeerlist allows you to specify the NTP server or servers you wish to synchronise time with. In this instance, each server’s DNS name or IP address should have a comma followed by the string 0×8. This instructs Windows to send requests to this external server in client mode. If you enter multiple servers, which I suggest, put the servers in quotation marks and separate each entry with a space. The value you specify here is written back to the NTPServer value in the time service’s registry key.

/syncfromflags tells the time service where it should sync time from. You can specify two entries for this – either DOMHIER or MANUAL. The former causes the time service to synchronise with the Domain Hierarchy (sets NT5DS in the Type key in the registry) whereas the latter tells the time service to sync with the server(s) you specified in the Manual Peer List. MANUAL sets Type to NTP.

/reliable sets the server to be a reliable source of time for the domain. Strictly it isn’t required, because the PDC Emulator in the forest root is always the most reliable time server, but I like to include it anyway.

Finally, /update notifies the time service the values have changed, so the new settings are used with immediate effect. If this isn’t included, the registry is updated but the new values will only be used by the time service when its service or the server itself is restarted.

After you’ve run that command, you might want to take a look in the registry to see what changes have been made, and whether they are as you expected.

Check Time Synchronisation

You may be intrigued to know whether the time sync is working correctly. You can do this in one of two ways.

The safest is to wait for a scheduled time sync to take place, or restart the machine. Either will trigger Event ID 35 to be logged in the System log. This event’s description shows the time server the machine is synchronising with. This will be logged on both the PDC Emulator and all DCs, member servers and workstations. You can check for this on member machines to ensure a DC in the domain hierarchy is being found and used correctly – and to ensure your custom NTP servers configured on the PDC Emulator are being used as intended.

Alternatively, putting your cowboy hat on, you can force a time synchronisation. Set the time a minute or two out from what it should be, then return to the command prompt and run w32tm /resync /rediscover. After a few moments, the above event should be logged, and a healthy time service should cause the time on the system to be set back to normal.

As a note, no time synchronisation will take place if the difference between the current system time and the new time provided by the time server is too great. A minute or two is fine, but I would not set the difference to be any more than that. The system checks this difference at each sync, and will reject the new time provided by the time server if it is too large.

Conclusion

You should now have an understanding of how the time service works and where it stores its settings in the registry. While time isn’t one of the most fun services an Active Directory administrator will work with, it is important you ensure the forest stays in sync if you want to avoid major problems with time skew, Kerberos and Active Directory in general.

Time: Reliable or Accurate?

The Windows Time service was initially created with the intention of maintaining loose synchronisation of time between all the nodes on a network. This is particularly important in Active Directory domains, where Kerberos Authentication requires two machines to have a difference of no more than 5 minutes (by default) between the client and server before a secure session can be set up.

When it comes to synchronising time, there are two words which are important but often cause confusion: Reliable and Accurate.

Reliable time is the most important in Active Directory, and is what Kerberos needs to work correctly.

For time to be reliable, the two machines’ time needs to be as close as possible to each other. For Kerberos, time readings within 5 minutes of each other will suffice as being designated reliable.

However, accurate time is something nice Domain Admins seem to be generous with giving to their users. They don’t have to. The most accurate time is time which exactly matches real worldwide GMT time, as tracked by the world’s atomic clocks.

Example

Suppose the real time now is 02:00:00.

If I set the time on both my Domain Controller and workstation to 18:00:00, nothing will break. Why? The time is still reliable – there is no difference in time between the two machines. However, the time is not accurate, and users will quickly complain the clocks on their machines are incorrect. Accurate time is little more than a nice feature; accurate time is by no means required for Windows to function correctly.

Conclusion

What I hope you have obtained from this article is that having an accurate clock on a workstation is not necessary. You could run your machines several hours out from normal time, but provided the time remains reliable, you won’t notice a problem.

Active Directory: PDCs and BDCs

On a number of forum threads I participated in recently, there was some confusion over the terms ‘PDC’ and ‘BDC’, and how they apply to a modern Active Directory domain.

In short, they don’t apply any more. The only exception to that rule is if you still operate a Windows NT-based domain.

Some History

On a Windows NT domain, one Domain Controller was designated the Primary Domain Controller (PDC). You were able to promote (although it was optional) one or more servers as Backup Domain Controllers (BDCs), which offer resilience by taking over the role of the PDC if it fails.

The process was very similar to today’s Active/Passive clusters in Windows Enterprise Server Failover Clustering. The PDC (Active node) was where all the domain update actions took place. These changes were later replicated to the BDCs (Passive nodes), to maintain an up-to-date Active Directory database. If the Active node/PDC failed, one of the BDCs would become the PDC and directory operations would continue while the problem was resolved.

How has this changed?

As I mentioned previously, this concept no longer exists – and hasn’t since Windows 2000. For the Windows 2000 release, Active Directory went through a major redesign.

The Domain Controllers in a Windows 2000, 2003 and 2008 domain now support multi-master replication. This means read and write operations can take place on any DC – changes don’t need to go through the PDC. Each change is later replicated between the other DCs in the domain.

This change meant more flexible environments spread across multiple sites, maybe in different countries or continents, could easily be created and managed.

What is the PDC Emulator (PDCe)?

So, that said, I hear you ask “So what is the PDC Emulator? Why do I still see references to the ‘PDC’ on my domain?”.

Active Directory has 5 FSMO roles (look out for a blog post from me soon about this topic). FSMO stands for Flexible Single Master Operation. Although most standard Active Directory actions can take place on any DC (the multi-master idea), some can only take place on one DC (single-master) to ensure no conflicts occur.

The PDCe role exists largely for backwards compatibility for legacy Operating Systems. They are designed to find the Windows NT PDC on a domain network, so designating a DC as the PDCe means these older Operating Systems continue to work correctly.

The PDCe could also be considered the most important Domain Controller in the domain – although you can survive without this DC if necessary. A number of tasks are assigned to the PDCe which help maintain the domain:

• The PDCe is the most reliable time server in the domain, which all workstations and servers (either directly or indirectly) synchronise their time to. There’s a good post on this on the W32time blog.
• Through PDC chaining, the PDCe has the final say in whether an account is locked out or if a user’s password was correct. Group Policy MVP Florian has a great blog post on this.
• If you are running in Windows 2000 Mixed Mode and still have Windows NT BDCs, the PDCe acts as the PDC for the Windows NT machines, and manages replication with them

Conclusion

Hopefully you now have a much better understanding of the terms PDC, BDC and PDC Emulator, and how they apply to your environment. Multi-master replication has transformed Active Directory; almost every change can be made on any DC anywhere on your network, rather than going through the PDC.

However, the PDC Emulator is still an important Domain Controller. While it is not as critical as in Windows NT days and your domain can survive without it, I suggest you keep the PDCe online and accessible from the other DCs as much as possible.

What’s new in Windows Server Backup R2?

The upcoming Windows Server 2008 R2 has a wealth of new features and improvements over the original 2008 release. One such improvement is in the built-in backup tool, Windows Server Backup.

Some History of Server Backup

In the early Windows 2000/2003 days, Microsoft’s entire line of products included a basic backup utility called NTBackup. This tool allowed administrators to configure simple backups for their servers, and was aimed primarily at those deploying servers in small to medium-sized business environments. It included technologies from Veritas, the company who originally developed Symantec Backup Exec.

The original release of Windows Server 2008 sparked an outcry when it was discovered NTBackup was replaced with a new Microsoft technology, Windows Server Backup. This tool was both an improvement and a set-back in backup technology; it supported backing up to Virtual Hard Disk (VHD) files (which can be mounted by Microsoft’s Virtual Server or Hyper-V for recovery of data), but it didn’t have support for backing up individual files/directories, or for backing up to a network share using its Graphical User Interface (GUI). Workarounds were available for continuing to support NTBackup on this OS, but they were not supported.

Networked Backup

Windows Server Backup now has support for configuring a scheduled backup to a network share via the GUI. Previously, you were required to run a manual batch command to use this feature — which led to a loss of fidelity in your backup procedure. As shown in the screenshot, the ‘Backup Schedule’ wizard, linked from the ‘Actions’ pane to the right of the backup console, now includes this much awaited ‘Backup up to a shared network folder’ option.

Windows Server Backup R2 allows backups to shared folders via the GUI

Unfortunately, functionality has been improved but there has been no improvement if you were intending to deploy any advanced backup programme which retains multiple copies. Selecting the Shared Folder option in the wizard prompts a warning to appear, indicating you can only store one copy of a shared backup when placing them on the network. This is a significant difference to harnessing the built-in backup-to-disk technology, where multiple backups are kept and only overwritten when the disk is full.

Shared Folder Backups Warning

Many companies deploying network backup are doing so as part of a larger backup scheme, which may later duplicate the backup to tape or hard disk for off-site storage. Anyone deploying shared network backup via this technique as their main backup should remember that it will allow a full server recovery, but won’t help in situations where documents created and destroyed 3 weeks ago need to be recovered; they will long since have been overwritten.

Granular File Backup

The original Windows Server Backup release only allowed the backup of server volumes – it was not possible to be granular in what files or folders you wished to backup. In 2008 R2, NTBackup support for specifying individual files/folders has been restored — for both once-only backups (started using the ‘Backup Once’ command and for scheduled jobs.

The backup wizard prompts you for the type of configuration to start a backup for. You can choose the recommended “Full Server” option, which includes all hard disk volumes and critical data required for a recovery, or you can choose the “Custom” option. Selecting “Custom” allows you to specify a list of files and folders to include in the backup, using a standard Windows Explorer view.

The "Custom" option unlocks granular backup of files/folders on your server

You can select only the files/folders you need to backup

Unfortunately, a Scheduled Backup job only permits one job to be configured at a time; you cannot configure multiple jobs to backup different data at different times, for example. This task still needs to be done using the Command Line Tools/Powershell cmdlets and Task Scheduler.

System State

The ability to take a System State backup using the GUI has now been added – this was only available via the Command Line in the original release. This is selected as an item after picking the “Custom” option in the backup wizard.

System State backups are not supported in the GUI

System State backups are useful backups to have; they contain a copy of all the critical system files and of any Active Directory database information. For Administrators of Domain Controller (DC) servers, this option allows you to take a backup of all the critical files needed to recover Active Directory in an emergency, without delving into scripting your backup jobs.

Also added for the System State is the ability to take a backup via the Command Line or the GUI to a remote network share. The command wbadmin start systemstatebackup -backupTarget:\\server\share will no longer fail but actually proceed to create a backup of the server to the remote file share.

Bare Metal Recovery

The installation of Windows Server 2008 R2 (or a Windows 7 client, incidentally) automatically creates a reserved partition – the “System Reserved” partition – which is usually just a few hundred megabytes in size. This partition contains the Windows Recovery Environment (WinRE), and can be used to boot the server in the event the Operating System becomes corrupt or otherwise fails to boot.

In the previous file selection screenshots, you will notice there is a new option – “Bare Metal Recovery” – which can be selected as a type of backup. This option is very similar to the -allCritical command on most Windows Server Backup Command Line tools in both the original and the R2 release, and akin to the ASR option in NTBackup.

A Bare Metal Recovery takes a copy of all the files needed to recover the whole server to its state at the time of backup, including most of its configuration. This type of backup is sure to get your server running again in the event of a disaster, although it isn’t guaranteed to include any of your critical data. If you do a “Custom” backup job, ensure you include the “Bare Metal Recovery” option as well as a backup of your important files and network shares.

Conclusion

Although Windows Server Backup R2 is not perfect, it continues to satisfy the requirements of smaller businesses who cannot or do not wish to invest in enterprise products. The recent enhancements discussed here can form a valuable backup plan for small businesses.

For the enterprise customer, or someone wishing to backup large amounts of data from multiple servers, Symantec Backup Exec, Acronis TrueImage or Microsoft System Center Data Protection Manager are much better choices for giving more control over backups and allow tape-based backups. However, for low levels of data and single server deployments, Windows Server Backup continues to impress with a wealth of new features in this latest release.

I originally posted this article on Experts Exchange

Netgear DG834 v4: VPN & File Sharing (SMB)

A router at one of my smaller client’s sites recently failed, so I purchased a new Netgear DG834 v4 to replace it. The intention was to restore the backed up configuration file from the old DG834 to quickly and easily recover the settings and restore an Internet connection at the client’s site. The client is reasonably small, so I could not justify the purchase of more expensive Cisco equipment.

The client’s network consists of 2 sites approximately 20 miles apart, each of which have a DSL line. Using a Netgear DG834 and a Netgear FVS114 at either end, a site-to-site VPN is created to allow traffic to traverse between the Windows Server at each site.

Using the new DG834 v4 with the restored config, file sharing across the VPN to any file shares at the remote site failed. This was the case from any machine, on or off the domain, and no matter in which direction we attempted to cross the VPN to access the file shares. This meant critical data at either location was inaccessible. However, ping traffic and remote desktop traffic worked successfully.

After investigating further, I confirmed my initial understanding that no firewalls are in effect across the VPN. However, firmware version 5.01.01 on the DG834 v4 has a bug which stops all SMB (Windows File Sharing) traffic traversing the VPN.

This bug was fixed in firmware version 5.01.09, as noted in the Netgear release notes:

Fixed an issue where browsing shares across a VPN (for example: \\192.168.1.2\sharename) would fail.

After upgrading the firmware to that version, the issue was resolved and workstations could access remote file shares again.

The firmware upgrade did not, in my case, erase any configuration on the router; this was a benefit as it meant I was able to perform the upgrade remotely.

Where do I put my ADMX files?

ADMX files are the new form of ADM files, the format which defines what Group Policy settings set what registry changes when they are applied. With Microsoft’s move to XML-based file formats and alongside their release of the new Office 2007 file extensions (DOCX, XLSX, PPTX etc.) the ADM format was also upgraded to ADMX.

People familiar with ADM files would remember that in order to have Group Policy Editor read the ADM file and add the settings to the policy, they would need to Add the template. However, for ADMX files, you cannot add them via the Add/Remove Template wizard in Group Policy Editor, because they do not appear as an option to add.

Windows reads the ADMX files on the system from a pre-defined location, and that location is the only location on the system where you should place the ADMX files. It is %systemroot%\PolicyDefinitions, where %systemroot% is normally C:\WINDOWS.

Any ADML files you receive with the ADMX files should be placed into a subfolder within PolicyDefinitions, named after their MUI ID. For example, a en-US ADML file would be placed into the directory %systemroot%\PolicyDefinitions\en-US.

Once you have stored your ADMX files in their respective locations, it is simply a matter of restarting Group Policy Management Console for the files to appear in the Group Policy Editor.

It should be noted that any form of ADM/ADMX file only needs to be present on the machine where the policies are edited from. It does not need to be present on every machine on the network. The ADMX files simply link the GUI of the GPO Editor with the appropriate registry settings to make; the registry settings are simply stored and processed at each client where the GPO applies.

Modifying Outlook Web Access Login Page

After a recent Exchange 2007 deployment, I was asked to make some modifications to OWA to make it more intuitive for some of the less technically-proficient users to make use of OWA more effectively, and to personalise the OWA site to the company.

In Exchange 2007, the business logic which renders OWA is contained within the Client Access Server (CAS) role. This is a new addition; in 2003, this logic was handled by the back-end mailbox servers, with HTTP requests simply proxied via the front-end servers which acted in a similar fashion to a gateway. Therefore, on a 2007 Server, you need to be modifying the login screen on your Client Access Server(s).

The location of the OWA static content is C:\Program Files\Microsoft\Exchange Server\ClientAccess\OWA. Before you begin making modifications, I would suggest you take a backup of this entire folder and store it safely. There is a lot of ASP.NET programming in the various files; unless you are a proficient .NET programmer, you could easily break your forms-based OWA logon and several other aspects of OWA with just a few wrong clicks.

The changes I made were as follows:

• I changed the header image on the front page (which says Microsoft Office Outlook Web Access) to include the company name below the text and the company logo in the upper right. This was particularly easy to modify using Photoshop, although any graphics editing suite would suffice.The file you need to take a backup of, then modify, can be found in the Current\themes\base folder below the ‘OWA’ directory referenced above. The file to modify is lgntopl.gif. It is in GIF format and opens in Photoshop as an Indexed image; if you are importing any graphics, you may need to change the image mode in Photoshop using the ‘View’ menu, to ensure colour content is retained.It looks particularly effective when the text for Company Name appears to the bottom right of the ‘Web Access’ line in the header image. That along with the addition of the company logo in the upper-right of the image personalises the OWA experience, and also acts as a potential security benefit – if users become used to seeing the header in this way, they may be deterred from logging in to any other OWA page which does not exhibit your modifications.
  
• The logon page can be modified too. It can be found in the Auth directory, and is quite aptly named logon.aspx. If you did not make a backup earlier, it is very important you take a backup of this file prior to making modifications. You will see why when you right-click the file and choose to Edit it using Notepad or Wordpad.The page is built around a standard HTML table, and it is particularly easy to pick through the content to find out what does what. If, like me, it is unclear to you at the beginning, simply comment out sections of code and refresh your OWA login page to notice the effect. The HTML comment tags are <!– to start a comment, and –> to end the comment. All the HTML code you wish the browser to ignore should be within the two tags – but there is no limit to the number of comment tags you can have per page.The features I removed from the login page was the  ’Public/Private’ login option and the ‘OWA Light’ version. The company decided it did not wish for these features to be visible to users. As a result, all users would login with sessions of type ‘Public’, and OWA would determine whether it operated in Premium or Basic mode based on browser (IE6 or above works in Premium, all other browsers operate in the cut-down, no frills Basic mode).I also added the following as a new row inside the main table which makes up the page:<tr>
  <td style=”width: 100%;font-size: 14pt; text-align:center;”>
  <p align=”center”>Welcome to <company>’’s Web Mail</p>
  </td>
  </tr>
  <tr><td><hr></td></tr>

  This added an additional line to the login page, once again to personalise OWA to the company.

Once you are happy with your changes, I suggest you make a note of exactly what changes you made. When any new Service Pack or Update Rollup applied to the server, it is likely the OWA files will be overwritten when the CAS role is upgraded, meaning you must implement your changes again. I do not advise that you copy/paste the original files back into their previous location for the simple reason that any SP/UR may upgrade these files, and overwriting them with your originals from the previous patch level will revert these changes.

I hope you have learnt something from this blog posting, and I look forward to hearing back from you as to how you have taken these modifications further with your OWA pages. You are not just limited to modifying the login page; within the ‘OWA’ directory there are plenty of other pages which can have changes made to them, and you can also access all the images which produce the various default themes and modify these as you wish.

Exchange 2007 access to all mailboxes for Administrator

Deploying Exchange 2007 can have its problems at the best of times. The separation of Exchange management from the Active Directory tools also has a knock-on effect when it comes to granting Exchange-related permissions en masse. This seemingly easy task is now proving to be a minefield.

So, how do you grant an Administrator access to all the mailboxes for an Exchange 2007 Mailbox Database?

Remove the Default Permissions

Before you start, you need to remove the default permissions at the Exchange Organization Level. These apply to all mailboxes in the organization and specifically deny any administrative-type user the Send-As and Receive-As permissions. This may cause confusion later, so it is best to remove them.

The user accounts and groups which are denied the ‘Receive-As’ permission at the organization level are:

• DOMAIN\Administrator
• DOMAIN\Domain Admins
• DOMAIN\Enterprise Admins
• DOMAIN\Exchange Organization Administrators

In order to remove the Deny entry for all the above users, the following command should be used:

Get-OrganizationConfig | Remove-ADPermission -User “DOMAIN\Administrator” -AccessRights ExtendedRight -ExtendedRights Receive-As -Deny

Replace DOMAIN\Administrator with the other entries in the above list to remove the permission for those accounts too.

The Commands

Having removed the default permissions, you can now set about implementing the permissions needed. Prior to discussing the actul Powershell commands to use, it is important that you understand the different types of permission which can be granted:

• FullAccess Mailbox Permission. This can only be granted at the individual mailbox level to a user or group of users; it allows the designated users the ability to access the mailbox via Outlook or the new feature to open another user’s mailbox in Outlook Web Access.This permission is granted directly on the mailbox using the cmdlet Add-MailboxPermission. An example might be Add-MailboxPermission -Identity JDoe -User MSmith -AccessRights FullAccess where MSmith is being granted the ability to access JDoe’s mailbox.This permission can also be granted via the Exchange Management Console. Selecting a Mailbox in Recipient view adds an option Manage Full Access Permission to the actions pane, where this permission can be managed in a similar fashion.The problem with granting permissions in this fashion is it has to be done on an individual mailbox basis. For granting permissions en masse, it would defeat the principles of granting permissions due to the administrative overhead of maintaining the ACLs. Instead, permissions should be granted on a common parent object and allowed to inherit to the child objects, in this case, the mailboxes.
• Receive As Active Directory permission. This permission can be set either at the mailbox level, or at a higher level in the Active Directory tree. It has the same effect as Full Mailbox Access, with the difference that it can be set at the store or storage group level, and therefore will be inherited down by all decendent mailboxes.Generic Active Directory permissions related to Active Directory objects are granted and modified at the Management Shell using Add-ADPermission. This cmdlet expects the -Identity parameter to be a full Active Directory path – I believe a Distinguished Name is expected. It is, therefore, much easier to pipe this path from the result of a previous command, particularly when handling some of the more complicated Exchange objects with complex DNs. For example, to grant these permissions at the store level (the store being an Active Directory object), I could use: Get-MailboxDatabase -Identity “My Database” | Add-ADPermission -User “DOMAIN\Group of Users” -AccessRights ExtendedRight -ExtendedRights Receive-As
  

The problem with granting Receive As permissions is while Outlook will obey them and happily display a mailbox where the Receive As permission is inherited, the new feature of Outlook Web Access which allows other mailboxes to be opened does not. For the OWA feature to work, the user must be granted explicit Full Mailbox access on an individual mailbox basis, to every mailbox they need to access.

My Approach

To achieve the ultimate objective of allowing Domain Admins to access a mailbox, either from Outlook or OWA, I chose to use several commands.

I first granted Domain Admins ‘Receive-As’ access at the store level using the command I described above. Via Outlook, these permissions would allow any Domain Admin to open these mailboxes as additional mailboxes.

To counteract the OWA restriction, I had to grant the Full Access permission across every mailbox. While this is very messy to maintain, it is currently the only option. Furthermore, as new mailboxes will not have the permission set by default, I use a Scheduled Task with a small PowerShell script, to set the permissions for every mailbox once per day.

My PowerShell script (.ps1 file) consists of the following:

# Matt’s Powershell Script (see tigermatt.wordpress.com) to add Full Mailbox permissions to all mailboxes in the Exchange organization
Add-PSSnapin Microsoft.Exchange.Management.Powershell.Admin -erroraction silentlyContinue
$userAccounts = get-mailbox -resultsize unlimited
ForEach ($user in $userAccounts)
{
add-MailboxPermission -identity $user -user “Domain Admins” -AccessRights FullAccess
}

Via Task Scheduler (Windows Server 2008), you can launch the script by specifying powershell.exe as the application, and “& ‘C:\path\to\script.ps1′” as the parameter. Note the double-quote followed by single-quote, and the requirement to close both quotes at the end of the command.

On the basis defined by your Scheduled Task configuration (I would suggest the task runs daily during the night, when the load on the server is low), the script will enumerate all mailboxes in the Exchange Organization, adding the required Full Access permission to the Domain Admins group.

This concludes my entry on granting various permissions in Exchange using Powershell. I hope I have cleared up some concerns regarding the differences between adding Mailbox Permissions and adding Active Directory permissions, and that this helps you.