Why you shouldn’t use PST files

They have been around for years and for thousands of Microsoft Outlook users and email administrators out there, they’d be lost without them: Personal Storage Table (PST) files. If you’ve worked with Outlook for very long, the name will immediately ring a bell; if you’ve ever administered Outlook, you may already know about the problems associated with this notorious file format.

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.

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.