Unfortunately, it would appear there is a bug in iOS 5′s handling of this situation. My iPad (running iOS 5.0.1) had many, many “incorrect password” prompts when I picked it up to use it this morning. There were so many that I was about to concede that the iPad as unusable until I found a computer to change my password on, as the password was yet to be set to a new value.

I would usually change my password directly from the iPad, by logging in to OWA, where I have enabled the ability to change a password when it has expired.

After some time of pressing “Cancel”, I was finally relinquished from the grasp of this prompt and was able to proceed to use the iPad normally.

It would appear to me that the number of prompts would be equal to either the number of Fetch attempts since the password expired and/or the number of occasions the iPad has tried to open a session for push delivery from the server. Of course, the iPad would have failed on every occasion, and it would appear it is being extremely verbose by displaying each and every failure.

Either way, the code should detect an incorrect password and show the “Incorrect Password” pop-up once only, as was the behaviour I experienced on iOS 4. If I choose to dismiss that message, I should not be repeatedly prompted with the same alert. As a tech savvy user, I repeatedly hit “Cancel”, but many of the users I deals with on a daily basis would try this a couple of times and then assume their iPad was unusable and not continue for fear of “breaking” something.

It seems I am not the first to come across this issue, but I will add my voice to those who hope this issue is resolved in a future iOS release.

For Exchange and AD admins, be aware this issue could potentially lead to lockout situations, dependent on your security policies.

My apologies for not posting much new over the last year or so! I can’t believe it has been 11 months since my last post, but I guess time really does move that quickly. I can assure you I have been tremendously busy, and I will endeavour to update you when I get a few seconds.

In the mean time, I have some very exciting news to report. Experts Exchange, the knowledge sharing site on which I am a very active member, recently contributed to a fantastic community project: the building of water wells in two communities in Ethiopia.

As part of the ‘EE T-Shirt Charity Challenge‘, the Experts with too many shirts for their wardrobes asked EE to donate the cost of those shirts to charity. EE happily obliged, and we donated many hundreds of t-shirts to a very worthy cause. The EE staff at the offices in California decided they would help too, so ran their own charity luncheon to raise funds for the second well to be built.

In conjunction with WaterRun, the EE community is pleased to announce the wells have been completed and are now providing safe, clean, unpolluted drinking water to two communities in Ethiopia. A resource I take for granted has changed the lives of some of these people. A real measure of community is how it can contribute to issues in the outside world, and I believe this is one brilliant example of the Experts Exchange members pulling together to help a very good cause.

Thanks to all involved. This is remarkable.

The following link will take you to the EE Corporate Blog, where the project is explained in more detail.

If you’re seeing any of the following errors just after upgrading to SP1, you might find the root cause and the associated fix is very simple – if so, read on.

• An error occurred while delivering this message
• This message has not been downloaded from the server
• Cannot Get Mail – the connection to the server failed
• In OWA: An unexpected error occurred and your request couldn’t be handled
• In event traces, imceaDomain must be a valid domain name.

Now, this issue was picked up and discussed in the release notes for 2010 SP1 as a known issue, but I didn’t clock this initially because I didn’t exactly read the notes thoroughly – a brief scan, perhaps, late in the evening, but nothing looked relevant on my tired eyes at the time. I’ve also already performed a number of SP1 upgrades elsewhere without experiencing issues, so I didn’t consider it important to refresh my memory by re-reading the notes.

The exact symptoms:

On the ActiveSync device:

Your email will sync, but there won’t be any content. The preview of the message text will display in the folder view, so you know something is there, but expanding the message to actually read it reveals the message: This message has not been downloaded from the server. Scrolling down, you can use the button to download remaining content – but it claims the message is 0 bytes in size and pressing this doesn’t do anything.

Message view - the messages just don't download

Sending email from the device resulted in a message: “Cannot Send Mail. An error occurred while delivering this message.” Unfortunately, all the errors issued by the Apple kit are fairly generic (probably because, in this instance, it didn’t actually know what the problem was – but I’m inclined to think it’ll always make you dig to find the root cause).

Non-Exchange accounts, such as Gmail, and potentially accounts on other Exchange environments configured differently to avoid this bug, worked absolutely fine.

Via OWA:

OWA, again, reports a generic error:

Expanding the details in the error or looking in your server’s event log, reveals an interesting exception message:

Exception message: imceaDomain must be a valid domain name.

If you’re not familiar with IMCEA (Internet Mail Connector Encapsulated Address), it was originally a method of inter-connecting mail environments by providing temporary addresses to users sending email via SMTP, but did not possess an SMTP email address. The mail system handled the encapsulation and subsequent reverse process in order to send and receive email for the user. The technology is still used today in the latest versions of Exchange, and you will often see cases where an SMTP address is unknown, so an IMCEA version of an X.500 address is displayed – often in NDR reports. According to Technet, Exchange actually uses IMCEA encapsulation for any address other than the default authoritative domain.

In this case, Exchange is having issues dealing with just that – the default authoritative domain. You see, if the friendly name you gave it has a space in it, or some other illegal character for a domain name, it triggers an error in the programming, which ultimately leads to this major loss of core messaging functionality.

As always, the fix is fairly simple. Remove any spaces from the friendly names of your accepted domains. You can do this at shell or the console – I prefer using the shell, in which case, use

Set-AcceptedDomain “Friendly Name of your default authoritative domain” -name “AnyNameWithoutSpacesOrIllegalCharacters”

Once the name change is complete, throw a restart on the MS Exchange AD Topology service during a period of planned system outage and functionality should come back. I pick that service because it restarts most of the others at the same time.

As a result of this issue, I will be forcing a new naming convention everywhere I manage Exchange, whereby accepted domains are ALWAYS named after the actual domain name for ALL accepted domains, thus containing no spaces and no other illegal characters. It transpired that the other sites were named in this fashion for the default domain anyway, which explains the reasoning as to why I never experienced this issue with those users.

The case of missing cmdlets was traced back to an issue with my user profile on this server. A test with another user account yielded no issues at the Management Shell.

A quick fix to this might be to obliterate the user profile using the System applet Control Panel, then log back in and have Windows generate a new profile. However, this is totally unnecessary and you’ll lose any special configuration, given how simple the actual solution is.

Exchange Management Shell uses a directory in the user’s roaming Application Data to store the Powershell module configuration settings. My module data had some… modifications. I don’t know the source of these changes, but it rendered the cmdlets missing. I suspected this was the case because shell loaded much more quickly than normal when it was broken – rather than show the status of the pending implicit remoting session, which I am used to seeing, it loaded and connected almost instantaneously.

The solution is to remove the C:\Users\username\AppData\Roaming\Microsoft\Exchange\RemotePowershell\your.domain.com directory.

After deleting this directory, restart the Shell. The startup process will create the directory and re-generate the module files, fixing your issue and allowing you to get on with whatever you needed to do!

Matt

—

P.s. I know I’ve been quiet lately, and for that, I apologise. For the past couple of months I’ve been involved in an almighty migration job, away from an awful managed service network (tip: NEVER opt for an outside company to supply your network. It falls apart!) to a vanilla Windows Server system. This came not a moment too soon but completing a migration of this magnitude for 2500 seats in the 6 week maintenance window is no easy feat!

I do have some articles on the backburner, and hope to get some out to you ASAP. Thanks for your patience, and thanks for reading!

The newer Microsoft operating systems from Vista onwards do not support the old, legacy format of the XP profile. Instead, users logging on to a modern OS for the first time will be given a new roaming profile with “.V2″ appended to their username in the roaming profile share. This is the version 2 profile, used by Vista up and totally isolated from the XP profile, including total isolation of the data it contains. In a phased roll-out of the newer Microsoft operating systems, you must follow best practices by using folder redirection to redirect user data on all systems to a common network location. This removes the data from the profiles, maintains consistency and ensures the user experience is the same on all network stations, without concerns over which OS is installed and therefore which profile and data the user will have access to. Plus, roaming profiles are just too slow for storing lots of user data anyway.

Unfortunately, Windows XP does not support redirection of the Favourites directory; this support was added in Windows Vista. One workaround I have seen is the built-in Vista redirection configured to redirect user favourites folders on newer systems to the legacy XP roaming profile share. This works, but it’s not particularly clean; redirecting data to a profile share rather than a user (home folder) share just isn’t right. It also causes data loss issues if a user’s profile must be reset; I work by the principle that only disposable data – stuff the users could live without – should be put into a user’s profile for precisely this reason.

Implementing Favourites redirection in Windows XP is a logical alternative; it isn’t particularly difficult either. I developed the following ADMX files to supplement the older ADM solutions which are available through a search on a popular web search engine. With 2008 or 2008 R2 Domain Controllers, the ADMX format is available for your use and I would highly suggest you make use of it. ADMX is XML-based and much, much easier to use than the legacy ADM language.

XPFavouritesRedirect.admx

<policyDefinitions revision="1.0" schemaVersion="1.0">
  <policyNamespaces>
    <target prefix="customFavorites" namespace="Microsoft.Policies.Favorites" />
    <using prefix="inetres" namespace="Microsoft.Policies.InternetExplorer" />
  </policyNamespaces>
  <resources minRequiredRevision="1.0" />
  <supportedOn>
    <definitions>
      <definition name="SUPPORTED_IE5" displayName="$(string.SUPPORTED_IE5)" />
    </definitions>
  </supportedOn>
  <policies>
    <policy name="IE_Favorites" class="User" displayName="$(string.IE_Favorites)" explainText="$(string.IE_Favorites_Location_Explain)" presentation="$(presentation.IE_Favorites)" key="Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders">
      <parentCategory ref="inetres:InternetExplorer" />
      <supportedOn ref="SUPPORTED_IE5" />
      <elements>
        <text id="IE_Favorites_Location" key="Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders" valueName="Favorites" required="true" expandable="true" />
      </elements>
    </policy>
  </policies>
</policyDefinitions>

XPFavouritesRedirect.adml (name this the same as the ADMX file and dump it in the language folder in your PolicyDefinitions directory)

<policyDefinitionResources revision="1.0" schemaVersion="1.0">
  <displayName>
  </displayName>
  <description>
  </description>
  <resources>
    <stringTable>
      <string id="IE_Favorites">Location of Internet Explorer Favorites</string>
      <string id="IE_Favorites_Location">The path to the favorites folder</string>
      <string id="IE_Favorites_Location_Explain">Specify the path to the location of your Favorites folder. This is stored in an expandable registry string value, so you can use environment variables, such as %HomeDrive%%HomePath%.</string>
      <string id="IE_Favorites_Location_Tip1">Specify the UNC path to the favorites location</string>
      <string id="InternetExplorer">Internet Explorer</string>
      <string id="SUPPORTED_IE5">at least Internet Explorer v5.01</string>
    </stringTable>
    <presentationTable>
      <presentation id="IE_Favorites">
        <textBox refId="IE_Favorites_Location">
          <label>Path:</label>
          <defaultValue>
          </defaultValue>
        </textBox>
      </presentation>
    </presentationTable>
  </resources>
</policyDefinitionResources>

The above is standard ADMX/ADML format which can be dumped in the correct locations of your Central Store (if you don’t have one, why not? Set one up, otherwise you will need to store them in the local store on each DC). In the GP Editor, it will appear as a policy in the standard Internet Explorer area under the User Configuration / Windows Components node.

The Favourites registry value in HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders is of type REG_EXPAND_SZ. The ADMX implements this with the expandable=”true” syntax, meaning from your perspective, you can specify environment variables in the GPO and these will be properly expanded by the system to their full paths. I personally use %HomeDrive%%HomePath%\Favourites to direct them to a subfolder of the user’s defined home folder location in their Active Directory user account properties.

This does not move any existing Favourites out of the profile and into the redirected location. However; this is fairly easy to script in a logon script or one-time operation. For new users, the Favourites directory will be created automatically, assuming the home drive exists, the user has permissions, quota is not fully used and so on.

It is a good idea to set the XP Favourites redirection policy in its own GPO object, then apply a WMI condition to filter the policy to XP/2003 and older systems only. Windows Vista and above support native redirection of Favourites, so you should use a separate, WMI filtered policy for Vista+ computers to redirect their Favourites to the same location as defined for XP clients.

So, I reverted to the fallback option. An APC UPS (the USB connected ones, not sure about serial) can run under Windows’ power management, being configured and monitored in exactly the same way a battery in a laptop would. Thus, they truly are plug-and-play; some less reputable brands require their own monitoring software and aren’t nearly as effective in my experience.

Alas, uninstalling the software never restored Windows Power Management. I waited… rebooted… checked control panel… nothing. No mention of a battery in the power options and the power meter icon was disabled in the task tray. I’d lost all shutdown functionality from the UPS. Yet again, a routine job involving a computer turned in to a match of man vs. machine.

The fix was surprisingly simple, didn’t involve edits to the registry (which I fear when it comes to drivers and hardware and critical things like power) — but unintuitive:

1. Open Device Manager, expand Batteries, locate the UPS and uninstall it. Be sure to uninstall the driver too when asked
2. Wait a few minutes for that to complete, then on the Action menu, hit Scan for hardware changes
3. Sure enough, the UPS was detected again, the drivers installed fresh and my power icon in the task tray immediately restored

It would appear APC Powerchute doesn’t fully tidy up after itself.

Although I run my own personal Exchange Server at home, I also run a couple of Google Mail accounts for subscriptions to online forum sites, newsgroups and suspect sites I might be required to sign up to occasionally. I’ve been caught in the spam trap before and I’m triply cautious not to share my main email addresses with anyone I don’t trust. Maybe I’m just overly cautious… but an email address is something you should treasure.

When I used Gmail for the first time, it was obvious Google had it right: for a free mail service for the average home user, it just works. You’d be hard-pressed to use all your 7.5GB mailbox quota (an ever increasing figure) and features like conversation view (recently introduced in Outlook 2010, thank you!), labels and archiving are handy.

However, I was never impressed by the email domain I received. Other parts of the world had the privilege of @gmail.com, yet a registration attempt from the United Kingdom for the past few years forced the longer googlemail.com at me. my alias@gmail.com still worked, but outgoing email and Google themselves still used the longer name.

You might ask: Why?

The answer goes back to a trademark dispute with an agency in the United Kingdom in 2005, which forced Google to drop gmail.com for new UK registrations. The webmail site was also rebranded for UK users with different logos. However, Google and the other party agreed to settle the dispute for £228k in 2008 and the rebranding back to gmail.com is now taking place.

I’m an existing customer. How do I get my @gmail.com address?

If you currently have a googlemail.com email address and want to use gmail.com as your “primary” address for sending mail from, you’ll need to convert it. Ironically, I hadn’t heard about this story until I accidentally stumbled upon it in Google’s Settings and I’d wager many, many users are in a similar position.

To claim your address, log in to Gmail, click Settings in the upper-right of the browser window, then select the Accounts and Import tab. Choose the Switch to @gmail.com option to begin the process. Per typical Google fashion, it’ll take you a matter of seconds.

Choose "Switch to @gmail.com" to claim your new email address

Rest assured your @googlemail.com alias will still exist and be routable; you won’t need to re-register with any sites or send out mass “I’ve changed my address” messages to anyone who currently reaches you on that address. However, any mail you now send will come from you@gmail.com, not you@googlemail.com, a significant improvement in my opinion!

Thanks once again, Google!

The team suggest Beta code will be available for your test environments later in the second quarter of 2010, sometime around June. Although I have no quibbles with Exchange 2010, the product group has still found places to make some useful improvements:

• Outlook Web Access (OWA) – performance improvements using more Web 2.0 AJAX-style programming, usability improvements and prettifying through the re-introduction of themes.
• Archiving and Compliance – My clients will benefit significantly from the ability to separate an archive mailbox from the user’s main mailbox – even to different mailbox stores. Frankly, server-side archive support was a long-awaited replacement to the problematic PST file or third-party tools, but moving data around within the same store just made no sense and we held off enabling the feature.

  Users with local Outlook AutoArchive PST files can also have their PST data imported directly into their Archive mailbox. With a bit of luck, we’ll begin to see many more PST free establishments.

• EMC/ECP Improvements – minor improvements are being made to the GUI management tools, negating the requirement for you to drop to Powershell for some configuration tasks.

Not mentioned were any bug fixes, although I suspect there will be a few. With a little hope, my pet hate – the preferred Global Catalog issue when creating and mounting a new Mailbox Database – will be resolved.

The Exchange Team have done a stellar job with the 2010 release so far and, unlike Exchange 2007, no real areas are lacking in functionality. However, there is always room for improvement and I look forward to seeing Beta code to play with later in the year!

See the full press release on the MS Exchange Team blog

Take a trip down memory lane

In the days of Windows NT, one may recall the Primary Domain Controller (PDC) and Backup Domain Controller (BDC) concept. The directory was structured such that every DC, whether a PDC or a BDC, had a copy of the directory database, but only the PDC could make changes to that database. The model was inefficient, negatively impacted growth and desperately needed improving if the product had any chance of surviving.

Enter Windows 2000. The Directory Service went through one of its largest scale rebuilds to date. Replication and management was significantly improved and the concept of having a multi-master directory was introduced. Although this design has been tweaked over the years, fundamentally, it has remained the same through the versions – because it works. Any DC anywhere in the domain can execute virtually any update to the directory. This scales beautifully, even on large, geographically dispersed networks with many thousands of users.

However, notice I said virtually any change. Since a change can take effect at any DC, there is the possibility that a conflicting change will be made in two locations concurrently – or before replication can occur. Active Directory must ensure these situations are accounted for. In most cases, it applies its complex Multimaster Conflict Resolution Policy, which essentially says the last change wins. However, there are several procedures which simply cannot conflict; these procedures are assigned to one of the five FSMO roles, which go on to be delegated to one or more Domain Controllers.

What are the FSMO roles?

There are nominally five roles present in the directory which reside on DCs nominated specifically by the Administrator to perform these tasks. All the roles are very important and constitute a single point of failure in all Active Directory enterprises. If you have a complex topology with more than one domain, some roles are domain-specific, so you can expect to have duplicates of some roles in every domain in the enterprise.

So far, three of the five roles have been covered. Those above are those I would consider the least critical FSMO roles in the forest. If you lose the DC delegated one or more of these roles, it’s no big deal — it may prevent a network administrator taking an action, but it will not impact the usability of the network. Losing the Domain Naming Master or Schema Master would create problems in regard to creating child domains or running schema updates, but these generally occur very rarely and checking this Operations master DC is up would be part of the planned engineering works. Similarly, losing the Infrastructure Master may cause integrity issues in the database, but given that it only runs its scan every two days in the first place, a day or two of outage will not generally cause an issue.

The latter two roles are much more crucial to the daily operation of the network and could very quickly become a limiting factor in its growth, usability or even the logon process if the DC(s) holding the roles are offline for any period of time. If the RID Master is lost, impact will only be felt by the Network Administrator if a DC depletes its pool of RIDs. On busy networks, this could potentially occur in a matter of days through the creation of new security principals. However, loss of the PDC Emulator could directly affect your users — you’d better have a substantial help desk ready for a spike in call volume if this DC is down for an extended period of time. For example, with the most authoritative source of time unavailable, time skew could eventually occur between DCs and computers in the enterprise and/or domain, lending itself to Kerberos authentication errors and ultimately, failed logons. While it would not be an immediate issue to take this server offline (provided you do not have any legacy applications), this would be the role I would be most concerned about in the event of a DC failure.

Conclusion

If you are still reading, well done! This article covers several aspects of Active Directory in detail, including low-level database processes unseen at the surface – particularly via the GUI. However, FSMO roles are a crucial component of your deployment — having an understanding of the underpinning concepts will help with their placement, deployment and high availability concerns within your enterprise.

In any corporate environment – or, for that matter, any environment with an Exchange Server – the use of PST files as a permanent solution to an email administrator’s problems should be banned. Let’s find out why.

Problem 1: File Sizes and Data Security

The number one issue with the PST format prior to Outlook 2003 was that it was ANSI (American National Standards Institute)-based. The ANSI PST format has a maximum size limit of 2GB, and other limitations exist with regard to the number of items which can be stored per folder. However, there was a particularly problematic bug in the Outlook software which allowed data to be written to ANSI PSTs past the 2GB limit without warning. This would result in data loss, at least past the 2GB limit, but potentially loss of all the data stored in the file.

To address these concerns, Outlook 2003 and higher introduces a new PST format which runs on Unicode instead. This format stores up to 20GB of data, but it should be noted that upgrading Outlook does not automatically upgrade any PST file(s). This must be completed manually, by creating a new Unicode file and transferring the data across.

Despite the improvements made, PST files are still susceptible to corruption issues – which will result in lost data. These become particularly prevalent as files become larger or you increase the volume of data which moves through the file. For most users, the prospect of losing precious or business-critical emails, reminders, tasks and contacts could be cause for significant concern. It shouldn’t come as a surprise that you should make a regular backup of your PST file(s), but this is not completely safe, as a PST can go for weeks or months in a partially corrupted state before you realise you have a problem.

Problem 2: Network Access and Backups

PST files must be stored on a local hard disk. Accessing them over a network is not supported by Microsoft. Instabilities in the network, loss of network connectivity, speed issues in reading and writing from the file server can all cause issues — particularly for sensitive PST files, which are so very easily corrupted.

This has two implications for system administration:

Firstly, backups are already difficult to maintain, due to the issues with corruption going undetected, but will become ever more difficult to implement. As the PST cannot be run from the network, you must configure backups on each machine individually – and must ensure the backup does not run while Outlook is running. Backing up the Exchange Server is rather pointless, as the data is offloaded into the PST when the user logs in.

Second, your cost of administration increases significantly. Considering a typical organisation, which may have remote workers and several sites across different areas of the country or perhaps throughout the world, moving administration away from the server and towards the client lessens the design principles surrounding central administration, requiring more admin time to perform repetitive tasks on PST files. The system may quickly grow beyond your control, becoming exponentially difficult to track and maintain.

Problem 3: File Sharing and Remote Access

PST files do not natively support file sharing between multiple users simultaneously. If you attempt to configure this, the mail file may be corrupted — not to mention the fact you would need to run the file over the network, so problem #2 has already been invoked.

Storing data in PST files also has no benefits for remote access either. Exchange’s Outlook Web Access (OWA) (or Outlook Web App, in Exchange 2010) allows users to remotely access their mailboxes, providing a near Outlook user interface for doing so. Data in PST files has usually been removed from the mailbox, so immediately becomes inaccessible to the user remotely.

Problem 4: Inefficient use of resources

You’ve invested in a powerful Exchange Server. It: has large, redundant disk arrays, processing power and RAM capacity; cost you thousands to purchase the hardware and software licenses; adds significantly to your energy and data centre cooling bill. If PST files are in use, your server is essentially going to waste; the functionality of the server you are actually using is essentially the same as a free Linux mail server distribution running on an old workstation supporting POP3 clients.

But…

Despite the considerations above, you might still be wondering how to work around those common problems which PST files are oh so convenient for solving.

Use 1: Archiving

This is a mis-conception, brought about largely by Outlook’s desire to continue annoying its users with AutoArchive prompts. There is no reason whatsoever that mail should be archived to each user’s local PC. Consider the actions you would take to archive files off your file server; where would you put the archived data? On your own PC? On your manager’s? On the CEO’s? You’d do none of those three, as the data is unlikely to be backed up, and you cannot assure data security. Instead, you’d find some space on a share on your archive server – or create a LUN using spare space on one of your SANs.

The same applies to email. Off-loading email from your Exchange Server to user PCs has significant risks attached to it. Instead, you should use an enterprise mail archiving solution. The product I usually recommend is Symantec Enterprise Vault, although there are many others. The main benefits? Data is still stored centrally, under the guise of your retention policies and backup process. To the end user, they can still view archived emails using a handy web interface (yes, a web interface – providing remote access to the archive).

Okay, but what about when disk space on my Exchange Server runs low or I hit the store size limit?

UPGRADE THE SERVER! Exchange 2007 and 2010 do not impose a hard limit on the mail stores, and you shouldn’t be trying to run a mail server with little disk space or database space remaining. Archiving to PST is a quick solution, but one which won’t work in the long run.

With the soon-to-be Exchange 2010 release, significant changes have been made, one of which is the addition of archiving support. Each user can be given a separate ‘archive’ mailbox; it is attached to their main mailbox, but allows for data to be archived for long term storage. The settings governing when and how mail is moved to the archive are controlled by retention policies, giving the administrator greater control over retention. Again, the archive store is available remotely via Exchange 2010′s Outlook Web App.

Use 2: On the road

For users on the road, there is no need to store their mail in a PST file. Cached Exchange Mode is available in Exchange 2003/Outlook 2003 and higher, allowing users to work offline with a cached copy of their mailbox. When they reconnect to the network, the changes are seamlessly synchronised back to the server.

Use 3: Exmerge/Export-Mailbox

This is just about the only use of PST files which I can agree to — and I’ll admit, I’ve used this approach myself. If you migrate to a new mail system or rebuild your Exchange system, sometimes you cannot avoid using exmerge (or Exchange 2007′s export-mailbox management shell cmdlet) to take handy copies of the mailboxes – which can later be re-imported to the new system. For moving mailboxes between servers, you would use the Move Mailbox wizard – but for large scale rebuilds, exmerge is sometimes your friend.

Be cautious though; Exmerge uses the ANSI PST format, so you will need to meticulously plan your export and import procedure for larger mailboxes.

Use 4: Home Users

These are the people who the PST is most applicable to. If you are connecting via Outlook to a Post Office Protocol (POP) host to download your email, that email will be stored in a PST file. The fact you don’t have an Exchange Server doesn’t change any of the points above, though; that PST is still susceptible to corruption. If mail is deleted off the server, this could lead to data loss.

For this issue, you really have two solutions. The POP3 account in Outlook can be configured to leave email on the server. This acts as a backup; if your PST file becomes corrupted, the ISP still has a copy of your messages, so they can be downloaded again. To configure, open the Tools > Account Settings dialog in Outlook. Select your POP3 account, choose Properties, press More Settings, then switch to the Advanced tab. Under the Delivery section at the bottom of the window you should check the “Leave a copy of messages on the server” checkbox. If you want a backup of all your mail, don’t enable the option to remove it from the server after a certain time period.

The disadvantage to the POP3 solution becomes apparent if you move to another computer or access your mailbox via your ISP’s webmail interface. The message state information (tracking of read/unread or whether the message has been replied to or forwarded) is not transferred back to the ISP, so all the mail you thought you had read and handled will still be marked unread on the ISP’s server.

My preferred solution, and the one I use regularly, is an Internet Message Access Protocol (IMAP) account. The IMAP protocol is another mail protocol used to access email; it stands alongside POP. However, using IMAP, you replicate a client-server topology very similar to connecting to an Exchange mailbox with Outlook in Cached Exchange Mode. With IMAP, email generally remains stored in your mailbox at the ISP until you specifically delete it. Nevertheless, you can’t get away from PST files completely; they are still there when you use an IMAP account, as Outlook uses them to make a cache of the data for working with the IMAP account in offline mode. However, as the PST isn’t the only location where your data is stored, any corruption is not going to lead to data loss.

It should be noted that both the POP solution for leaving data on the server, as well as the IMAP solution, both have drawbacks, as items in your Calendar, Contacts or Tasks folders will not be stored on the server. IMAP does not support special folders – such as the Calendar or Tasks – and these will not be replicated back with a POP account, so you will still be using a PST file to some extent. Unless you move entirely into the cloud (use web services for email, calendar and contacts) or purchase your Exchange Server, you won’t be able to easily get away from this.

Conclusion

I’ve covered a fair bit of information regarding PST files here. Hopefully, my points detailing why the use of PSTs is so impractical will now encourage you to reconsider your PST usage, archiving practices and retention policies.

With all your user mail stored safely on the Exchange Server, rather than local PCs, assistants can become delegates for their managers, looking after their mailbox; the administrator can rest assured that all data is centrally stored and backup up and you can turn off Outlook AutoArchive, relieving end users of that annoying prompt every couple of weeks.

This article was originally published at Experts Exchange.

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.

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!

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 often use the servers closest to me which participate in possibly the largest time service, the NTP Project (list of time servers). Be aware that if you are bound by SLAs (my company certainly is), by its very nature, the NTP project most probably isn’t the resource for you.

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.

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.

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.

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.

I originally posted this article on Experts Exchange

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.

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.

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.

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.