Notes From The Field : Server 2008

Easy Web Application Installs

jdphilli — Wed, 08 Apr 2009 16:16:00 GMT

Normally, when people start talking about blogging or hosting a custom web application like Gallery or WordPress, they tend to think of hosting them on Linux. This has generally been the case for a long time. In fact, for a while, I even hosted my personal sites using this software on the LAMP platform. LAMP, for those of you not in the know, stands for Linux Apache MySQL PHP and is considered the open source stack for web applications.

When I first came to Microsoft, I felt I should at least attempt to host the application on a Microsoft platform. Thus started my journey.

I have a server at home which was running the entire application stack running the Fedora Core variety of Linux. All of the packages of applications are generally very easy to install on this platform as most open source developers have historically targeted Linux-based systems. So, as an experiment, I installed Windows Server 2003 and IIS to replace the “LA” in LAMP with “WI”. [Yes, I know: the WIMP platform doesn’t sound so good, but that will change as you will read later.]

To my utter amazement, the applications ran great – even faster – on Windows and IIS on the same hardware.

This is not to say “easier”. Since these platforms are geared towards Linux, the text files which manage configurations are generally Unix formatted which mean no CR-LF (carriage return line feed) which is necessary in DOS-based text format. There have been installers in the past for say, PHP and MySQL, but not so much for the applications themselves. These were usually zipped file and folder hierarchies, leaving much manual configuration to the user.

This is now no longer completely true. While not totally false in many cases, this is beginning to change. Hosted on Microsoft’s web site is a Web Platform Gallery complete with installations for many popular web applications. Visit http://www.microsoft.com/web/gallery/ to see this for yourself. Many applications like WordPress, DasBlog, SubText, Gallery, and several others have been incorporated into the installer. Using the installer will copy the installation files to their proper place and even configure IIS for you with the appropriate settings.

As a part of my continuing effort to learn technologies that are not necessarily part of my core skill set, I decided to migrate from MySQL to Microsoft SQL Server 2008 as my blogging/Gallery backend database – changing the platform acronym to WISP. I was pleased to find out that Gallery now supports this as the backend, so I also set out to determine if my current installation of WordPress would support it. Presently, it does not and the developers do not feel the need to try. So, I’m investigating moving to another application that supports SQL Server.

Perhaps I’ll check the Microsoft Web App Gallery for suggestions…

Remote Office Server Consolidation With Hyper-V and BitLocker

jdphilli — Wed, 04 Jun 2008 19:28:00 GMT

Do you remember the days when servers for remote offices were under someone's desk or in a janitor's closet? How about in a reconfigured bathroom stall? (Yes, I've actually seen these) Are those days still now for you? The problem of securing remote branch office servers is still a common one. I've seen broom closets, dusty storage rooms, and even a server being used as the local administrator's desktop workstation all as part of major enterprise branch office infrastructures.

A main concern with these kinds of installations is security. Since there isn't usually a dedicated, secure server room to house these servers, they share access with what are normally commonly accessed areas: like an office trailer at a construction site, or under the receptionist's desk. Another concern with branch offices is space - which is why these servers end up under desks or next to the water cooler in the copy room. Maybe the site has enough room for one server, but two? Three? Five? Not likely.

How do you secure these servers as well minimize the number of servers you deploy to the branch office?

First, let's start with Hyper-V. What is Hyper-V? It's the new virtualization engine for Windows Server 2008. It is a radical change from Virtual Server and the performance is much, much better. Among the many benefits with Hyper-V, you can run native x64-based guest OS installs. This is especially important when installing products like Exchange 2007.

For small branch offices, Hyper-V provides the option of packing several virtual servers on one physical box, thereby simplifying the amount of infrastructure necessary for site deployments: less power requirement, fewer network drops, fewer cables, less space, etc.

Now that you've decided that virtualization is a good thing for small offices, you think: "But wait! If someone swipes the server from the construction trailer, they'll have copies of my sensitive data!" This is where BitLocker comes in.

First introduced with Windows Vista, BitLocker is full volume encryption for Windows (Vista and Server 2008). That small branch office server with Hyper-V you just built can now be configured to use BitLocker to encrypt its drives, thereby securing the installed virtual machines and making them practically inaccessible even to those who would steal the hardware.

You can even put a more secure spin on this combination by making the host OS a Server Core installation. This will greatly decrease you attack footprint on the host as well as simplifying the patching process. A smaller OS footprint means fewer vulnerabilities. Fewer vulnerabilities means fewer patches for Server Core. Fewer patches means fewer reboots, which is always a good thing.

Installing Server Core as the host OS also provides an additional layer of security: the command line interface. There's no GUI with this OS which makes it harder for the amateur site administrator to inflict any damage.

In summary, a Server Core installation of Hyper-V protected with BitLocker (and possibly a Read Only DC installed as a VM, but we can talk abou that later) will give you a great option for deploying to less secure and “infrastructure challenged” environments.

You should try it.

Upgrading Your SYSVOL to DFS-R Replication

jdphilli — Sun, 27 Apr 2008 08:13:16 GMT

Many papers and KB articles have been posted about the "old-style" SYSVOL replication, or FRS, dealing with the various problems and the difficulty of recovering from an FRS disaster. In light of this, the product group has finally come up with a solution to the "woes of FRS": DFS-R SYSVOL replication. With Windows Server 2008, SYSVOL replication can now rely on DFS-R.

Why would you want this?

Let's look at some reasons why. First, the Branch Office Guide states a soft limit of 1200 DCs per domain due to a limitation of FRS. Not that it won't work, mind you, but that the difficulty of recovering from a disaster with that many or more DCs approaches impossibility... or at least extreme difficulty.

It's also much faster. FRS replicates the whole file when it changes, while DFS-R only replicates the changed bits. For example, if you have a 5MB file in which the spelling of a single word is changed, with FRS the whole 5MB must be copied. With DFS-R the copy would only be a few KB (I don't know exactly how much off-hand, but from what I've been told it's quite small).

Migrating to DFS-R is done in four stages: Start, Prepared, Redirected, and Eliminated. (The most detailed information is contained here: http://blogs.technet.com/filecab/archive/2008/02/08/sysvol-migration-series-part-1-introduction-to-the-sysvol-migration-process.aspx)

So: how do you do it? It's actually quite simple. First, your domain must be in native 2008 mode. This requires that all your DCs be upgraded to Windows Server 2008. Included in Windows Server 2008 is a utility called dfsrmig. The next thing you should do is check your SYSVOL replication health. Do this with the command:

repadmin /ReplSum

You will need to deal with any issues that are shown before you proceed with migration to DFS-R. Once you're ready, you can begin the migration by typing:

dfsrmig /SetGlobalState 1

What this does is set a flag on your DC (the one you started with) saying that you'd like to start the DFS-R migration process. This change then replicates out to all the other DCs in the domain. You cannot proceed to state 2 until all DCs have reached state 1. You can check this by running the command:

dfsrmig /GetMigrationState

You can slowly go through the migration by issuing the command to set the state to 2 and then to 3 one at a time, or (I found this out recently) you can start the whole process by going straight to "2". I don't say "3", although you could do that, because you'll want to sit at 2 for a while and verify that your new "SYSVOL" redirection is working fine. Once you're fully satisfied that the redirection is working properly in the environment, you can issue the "3" command (or Eliminate) and this will clear all the information from the old SYSVOL directory.

The great thing is that at any stage prior to Eliminated, you can roll back to the beginning. For those procedures, you would simply step the state back to 0 and it will slowly trickle back to the original state. You can only do this if you haven't gone to the Eliminate stage. And of course, if you do roll back, you'll need to copy all the new or updated files back into the old SYSVOL directory from the SYSVOL_DFSR directory.

If you do decided to implement DFS-R for SYSVOL or any other purpose, be sure to manage and monitor the system - and configure it properly to begin with!

Here are some tips to avoid slow replication with DFS-R: http://blogs.technet.com/askds/archive/2007/10/05/top-10-common-causes-of-slow-replication-with-dfsr.aspx