Search

Error upgrading MOSS 2007 to Service Pack 1

Posted by Amber Pham on May 12th, 2009

I needed to upgrade MOSS 2007 farm on a Windows 2003 Server from the RTM version to Service Pack 1 as a required step to prepare for a migration to Windows 2008 64-bit.  The process involved installing the WSS 3.0 SP1, ignoring the Configuration Wizard, running the MOSS 2007 SP1, then running the Configuration Wizard.  In this case, the  last step of the Configuration Wizard failed.   The Wizard screen said to look in the event log, which showed three errors similar to this:

Configuration of SharePoint Products and Technologies failed.  Configuration must be performed in order for this product to operate properly.  To diagnose the problem, review the extended error information located at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS\PSCDiagnostics_5_8_2009_19…log, fix the problem, and run this configuration wizard again.

I consulted the PSCDiagnostics log, but all it did was repeat the error message shown above.  Looking in the Upgrade.log file, the last entry looked like this:

[SPManager] [INFO] [5/8/2009 7:45:10 PM]: Inplace Upgrade session finishes. root object = SPFarm Name=SharePoint_Config, recursive = True. 1 errors and 0 warnings encountered.

Searching back up through the file, I found one area where errors were reported:

[SPManager] [ERROR] [5/8/2009 7:45:03 PM]: Pre-Upgrade [SPSite Url=http://sitename/sites/TestSite] failed. Microsoft.SharePoint.Upgrade.SPSiteWssSequence has the ContinueOnFailiure bit set. Moving on to the next object in sequence.
[SPManager] [ERROR] [5/8/2009 7:45:03 PM]: The system cannot find the path specified. (Exception from HRESULT: 0×80070003)

The error was caused by a site that is no longer there.  This happens sometimes when a site is deleted from SharePoint, but it doesn’t get removed all the way from the configuration database.  It will often show up in Central Administration after you have deleted it.

Looking through the Microsoft SharePoint Service Pack 1 installation documentation, there were no fixes in the troubleshooting section that fit this scenario.  I found many articles about removing orphaned sites, but this site was not a true orphan (its parent was not missing).  If you have a true orphan, you can use the stsadm parameter databaserepair.

In this case, the solution was to detach the content database within SharePoint then reattach it.  When you do that, it removes the old entry from the configuration database.  This operation can normally be done by detaching and reattaching a content database within Central Administration, but since the upgrade was not complete and the farm disabled, I used stsadm.

stsadm –o deletecontentdb –url http://sitename –database contentdatabasename –databaseserver sqlserver\sqlinstance
stsadm –o addcontentdb –url http://sitename –database contentdatabasename –databaseserver sqlserver\sqlinstance

*The deletecontentdb parameter does not delete the database, it only detaches the reference to it from your SharePoint farm.

After this, I ran psconfig at the command line:

psconfig -cmd upgrade -inplace b2b -wait -force

Once that completed successfully, I launched the Configuration Wizard manually from All Programs > Administrative Tools > SharePoint Products and Technologies Configuration Wizard to get visual confirmation that the upgrade was completed.

After upgrading SharePoint, always check the Upgrade.log in %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\LOGS for “Finished upgrading SPFarmn Name=<configuration database>”, “0 errors and 0 warnings” at the end.

Breathe new life into a bogged-down CoyotePoint Load Balancer with DSR

Posted by Irving Popovetsky on April 7th, 2009

Let me start by saying this:   I am not a fan of CoyotePoint load balancers.    My support experiences so far have all been atrocious.   The system architecture is a cheap imitation of F5′s BigIP architecture from a decade ago which constantly limits me.    I’m convinced that people only buy these things because they’re cheap.

I’ve been working with a customer who’s exceeded the throughput capabilities of their Equalizer E350si load balancer.   Although the marketing materials will tell you that this unit is capable of throughput up to 700Mbps (hah!),  we were maxing out and dropping packets above 50 Mbps.

Rant:  You see, the problem lies in Coyote’s system architecture.  This E350si is powered by a NetBurst-architecture Pentium 4 2.8Ghz, with HyperThreading disabled.   Coyote uses a FreeBSD-4 based kernel, which was well known for it’s slow timers, slow interrupt handling, and immature device polling implementation.  In this classic system architecture, each incoming packet generates an Interrupt Request (IRQ), which must be serviced by the CPU in a time-slotted fashion.   So what we have is a load balancer which reports it’s CPU as being mostly idle,  but in reality cannot handle packets quickly enough.   THIS IS NOT HOW YOU DESIGN NETWORK EQUIPMENT, PEOPLE.   End rant.

Good news:   In version 8, Coyote introduced a new mode of operation called DSR, or Direct Server Return.  DSR is quite clever, really, because it get’s around Coyote’s packet handling limitation (to a big degree) by handling the incoming network packets, but allowing the web servers to respond directly to clients.   This cuts the number of TCP packets the Coyote has to process in half,  and cuts the number of Ethernet frames by much more if you consider that the return packets are much larger.

Here’s how it works.   In a traditional setup,  the Coyote receives a packet on its external interface (em1), makes a load balancing decision, and then forwards to the packet along to a host behind its internal interface (em0).   Most shops NAT here as well, for security and/or IP address conservation reasons.   So the Coyote must perform Layer 2 – 4 (or 7) processing of the packet as it receives it,   then make a load balancing decision,  then translate the packet (that’s the T in NAT),  then re-process the packet going out the internal interface.   Then, rinse, lather, repeat for the return packet.   Such is the life of a typical load balancer.

In DSR mode, you start by chopping off the Internal interface of the load balancer altogether and eliminating NAT.   This requires moving your webservers onto publicly routable IP addresses, so please make sure they are firewalled properly.   Now you have your load balancer and webservers all on the same ethernet segment.   You create a VIP (Virtual IP) on the load balancer, and then add that SAME VIP address as a loopback address to the webservers!

You’re probably scratching your head, wondering how this is going to work.  I know that I was.  Here’s the magical part.   Only the load balancer responds to ARP requests for the VIP.  The webservers have Apache listening on the VIP address,  but don’t respond to ARP requests at all on that address.   Each incoming packet is sent from the router to the MAC address of the load balancer,  which then makes a load balancing decision and then sends an identical copy of that packet to the MAC address of the web server.   Let me say that again.  The load balancer performs no more translation, it literally just copies the packet over to the webserver.   Since the source MAC address is unchanged,  the web server replies directly to the router and skips the load balancer entirely.

Sounds a bit scary, but works well.  Except for one thing.   In their brilliance,  the Coyote folks created a section in the Manual with configuration instructions for “Linux/Unix Systems”, but ACTUALLY put in instructions for BSD-like systems only.  Who runs FreeBSD anymore?   DON’T TRY THESE INSTRUCTIONS ON A LINUX SERVER UNLESS YOU WANT TO LOCK YOURSELF OUT.

On Linux,  the correct way to create the loopback address is by adding a “labelled” loopback interface,  but ALWAYS set the netmask of your new interface to “255.255.255.255″.   If you match the netmask of the VIP,  your webserver will stop responding to packets on it’s external interface.  Very bad.

So,  assume your public VIP address is 12.34.56.78  (fake, to protect the innocent),  and your webserver’s address is 12.34.56.80.   Create a loopback address like so:

/sbin/ifconfig lo:vip inet 12.34.56.78 netmask 255.255.255.255

Then, the output of “ifconfig -a” looks something like this:

eth0      Link encap:Ethernet  HWaddr 00:40:A4:8E:B0:1A
inet addr:12.34.56.80  Bcast:12.34.56.255  Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:47131905 errors:0 dropped:0 overruns:0 frame:0
TX packets:77804088 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5111837334 (4875.0 Mb)  TX bytes:104047655003 (99227.5 Mb)
Interrupt:177

lo        Link encap:Local Loopback
inet addr:127.0.0.1  Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING  MTU:16436  Metric:1
RX packets:1311164 errors:0 dropped:0 overruns:0 frame:0
TX packets:1311164 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:439975560 (419.5 Mb)  TX bytes:439975560 (419.5 Mb)

lo:vip    Link encap:Local Loopback
inet addr:12.34.56.78  Mask:255.255.255.255
UP LOOPBACK RUNNING  MTU:16436  Metric:1

If it all works, you should be able to confirm correct operation by using tcpdump or Wireshark/Ethereal on the webserver, and verifying that the SOURCE address is your VIP address and you’re seeing lots of 200 OK messages.

tshark -n -i eth0 -R http.response port 80

Lesson learned: High traffic WordPress Site Operation

Posted by Irving Popovetsky on April 7th, 2009

I recently had the pleasure of helping out with a WordPress blog which had gone supernova.   Within hours of being linked to from several major news sites,  the server couldn’t stay up for 10 minutes without something terrible happening.

Unfortunately, WordPress isn’t setup for high performance operation out of the box.  Each page request is very CPU and database intensive.

Under benchmarking, we discovered that each of the customer’s HP DL385 servers could serve between 5-10 WordPress page view’s per second, depending on the page.  (For the pedantic,  I’m considering anything that hits PHP as a page view.)  And this is AFTER I had put major effort into MySQL performance tuning.    Something had to be done, 5 page views per second is just not going to cut the mustard.

In comes the WP-Super-Cache plugin to save the day.   WP-Super-Cache is a plugin which seems like it should be installed with every WordPress instance by default.   It writes out entire pages to static .html files,  and then instructs Apache to serve up the static .html files directly (using mod_rewrite),  therefore avoiding any CPU-gobbling calls to PHP or the database.   But WP-Super-Cache is smart,  it automatically expires cached pages when the content is updated  (by the author, or via comments).

As a result,  we went from 5-10 page views per second to between 500-2000 theoretical page views per second.   At this point we were hitting bandwidth bottlenecks,  which is where I like to be.   As long as webservers can serve up enough data to fill their own pipe, you have happy system administrators (and UNhappy network administrators).

Critical PDF Vulnerabilities in Blackberry Enterprise Server

Posted by Amber Pham on January 13th, 2009

Research in Motion has just released security bulletin KB17118 that announces a new set of vulnerabilities in the Blackberry Attachment Service that runs on Blackberry Enterprise Server (BES). According to Blackberry, “these vulnerabilities could enable a malicious individual to send an email message containing a specially crafted PDF file, which when opened for viewing on a BlackBerry smartphone, could cause memory corruption and possibly lead to arbitrary code execution on the computer that hosts the BlackBerry Attachment Service.”

It is strongly recommended that you read bulletin KB17118, then download and install the patch, called Service Pack 6 Interim Security Software Update 2, from http://www.blackberry.com/go/serverdownloads. The security bulletin also offers a workaround that reduces the functionality of BES but protects the server from exploits of the Attachment Service vulnerabilities.

The affected versions of the server software are BlackBerry Enterprise Server software version 4.1 Service Pack 3 (4.1.3) through 4.1 Service Pack 6 (4.1.6), including the latest maintenance release.

Recently, I got an excellent chance to put my money where my mouth is.

In the past, I’ve warned Windows shops to use unique local Administrator passwords wherever possible.  I’ve even proven the dangers of using the same local Administrator password during a penetration test in 2007.   Combine this with the fact that  I rarely have anything polite to say about VBscript (it’s not a pretty language to work with), and we have the perfect karmic storm.

Yours truly, coding in VBscript, tasked with setting a unique, strong passwords on each one of a few hundred machines.   Here’s what I came up with:

' ChangeLocalAdminOnServers.vbs
' Created by Irving Popovetsky (irving@prostructure)
' 12/15/2008, ProStructure Consulting
'
' Warning:  This script will begin changing passwords as soon
' as it collects a complete list of machine names.
'
' Read and understand this code carefully before executing,
' and always remember to fill in your own variables where appropriate.
' We assume no liability for damages that may be caused by running
' this code in your production environment!!

On Error Resume Next

Dim fso, MyFile
Set fso = CreateObject("Scripting.FileSystemObject")

' ***CHANGEME*** Change the output file to a location you trust, like an
' Encrypted folder or USB stick that can be stored away
' In the future, this could be improved to output directly to PGP or equivalent.
Set MyFile = fso.CreateTextFile("c:\Temp\Changedservers.txt", True)

Const ADS_SCOPE_SUBTREE = 2

Set objConnection = CreateObject("ADODB.Connection")
Set objCommand =   CreateObject("ADODB.Command")
objConnection.Provider = "ADsDSOObject"
objConnection.Open "Active Directory Provider"
Set objCommand.ActiveConnection = objConnection

objCommand.Properties("Page Size") = 1000
objCommand.Properties("Searchscope") = ADS_SCOPE_SUBTREE 

' ***CHANGEME*** Fill in your own Domain name here
objCommand.CommandText = _
    "SELECT Name FROM 'LDAP://dc=DOMAIN,dc=INTERNAL' WHERE objectCategory='computer'"
Set objRecordSet = objCommand.Execute

objRecordSet.MoveFirst

Do Until objRecordSet.EOF
    strComputer = objRecordSet.Fields("Name").Value

	' ***CHANGEME*** Skip the Domain Controllers  - fill in your own values here
	if Instr(1,strComputer, "DOMAINCONTROLLER1") Then objRecordSet.MoveNext
	if Instr(1,strComputer, "DOMAINCONTROLLER2") Then objRecordSet.MoveNext
	if Instr(1,strComputer, "DOMAINCONTROLLER3") Then objRecordSet.MoveNext

	' Irving - Random password
	Dim intUpperLimit, intLowerLimit, strPassword
	strPassword = ""
	intUpperLimit = 126
	intLowerLimit = 33

	For i = 1 to 12
	    Randomize
	    intASCIIValue = Int(((intUpperLimit - intLowerLimit + 1) * Rnd) _
	        + intLowerLimit)
	    strPassword = strPassword & Chr(intASCIIValue)
	Next

	'  Perform the Action.  Write out the computername/password then execute
	MyFile.WriteLine(strComputer & "   " & strPassword)
	Set objUser = GetObject("WinNT://" & strComputer & "/Administrator")
	objUser.SetPassword strPassword

    objRecordSet.MoveNext
Loop

MyFile.Close

Credits to The Scripting Guy’s article on scripting the change of the local administrator password. Very funny article,  I’m a big fan of the Scripting Guy.

Now, there are certainly some improvements that can be made, and WILL be made if I ever have to use this thing again.   First off, the ability to define the output location and LDAP search path.   Second, automatically determining if a server is a domain controller and skipping it.  You DEFINITELY DO NOT want this script hitting a Domain Controller, because it will change the Domain’s Administrator account, and that can be a bad thing.  Trust me, I already learned that lesson, at least I had the password in my output file.

Interviewed for Inc. Technology

Posted by Irving Popovetsky on September 19th, 2008

I was recently interviewed by Michelle Rafter for Inc. Technology about best practices for Administrative Passwords.

Article link:  Psst! Whats the Password?

ProStructure’s major report for WSDOT and USDOT has been published

Posted by Irving Popovetsky on September 19th, 2008

ProStructure Consulting is pleased to announce the successful conclusion of its IV&V project for the Washington State Ferries Wireless High-Speed Data Network, and the publication of its full report on the website of the Federal Transit Authority!

Earlier this year, ProStructure completed a major IV&V (Independent Verification & Validation) project for the Washington State Ferries, a department of WSDOT, and the Federal Transit Authority, a department of USDOT.  The project focused on a new high speed ship-to-shore wireless network implemented on the Ferries system by contractor Mobilisa.

The full report is available here:  http://www.fta.dot.gov/documents/CAI-PSC-IVandV-Final-Report-20080910.pdf

From the FTA research site: http://www.fta.dot.gov/assistance/research/research_5638.html

I’m personally excited about the public release of this report for several reasons.   First and most importantly, we get to show the world the kind of truly first-rate work that we do.   Reports of this caliber are almost always locked away as “Highly Confidential” and never see the light of day.  Thanks to the FTA for ensuring that all of its research reports are made publicly available.

In addition to that, we get to show off some of the really innovate technology we put together for this project.  We built a monitoring platform for this project that was both weather hardened and security hardened.   Our locked, tamper evident, IP67 rated (waterproof) boxes were designed to be strapped to the side of the ferries like a flight recorder or “black box”,  continually running a suite of network tests against its twin unit located at the ferry terminal.


ProStructure's device aboard the Steilacoom II

Our yellow Test & Measurement Device aboard a WSF vessel

Irving Popovetsky aboard the Steilacoom II performing a final once-over of the unit before the test

Irving Popovetsky aboard the Steilacoom II performing a final once-over of the unit before the test


By utilizing the scientific method, we build and tested our hypotheses about the expected network performance.  We collected a great deal of addition information including radio statistics, GPS data and weather data.  Using this information we were able to understand how various external influences affected network performance.

For more details, check out the full report.

Hard drives: Magical, complex, and faulty.

Posted by Irving Popovetsky on July 7th, 2008

As a quick refresher before I make some recommendations to a customer,  I got to revisit the discussion of hard drives and how they like to fail.

Three articles on the StorageMojo blog are brilliant and worth a read or a revisit:

  • NetApp Weighs In On Disks – Val Bercovici of Netapp weighs in on disk failure surveys from Google and CMU’s Parallel Data lab.  Beware some marketing spin mixed in with some real gems of knowledge.
  • Google’s Disk Failure Experience:  Google’s analysis of failure rates among 100,000 drives.  It’s worth noting that Google uses cheap SATA drives almost exclusively in the cloud.
  • Everything You Know About Disks Is Wrong: The aforementioned CMU study, which has a nice comparison between cheapo SATA disks and fancy FC disks.

There are some critically important takeways in these articles and the surrounding commentary that we must never forget when safeguarding our data.   Most imporant points:

  • MTBF is a nearly irrelevant number. Storage experts are contending that Mean Time Beteween Failures is actually much closer between “consumer” SATA drives and “enterprise” FC drives than the marketing people want you to believe.
  • There is a huge amount of magic and complexity happening inside of every hard drive: Really, almost all of it is masked from users.   Hard drive controllers and their respective firmware has gotten insanely complex to keep up the increasing number of failure and error scenarios as disks get more dense.   The difference between two disk firmware revisions or code branches can make a considerable impact on drive reliability.
  • The REAL difference between the low and high-end is RAID controller and drive firmware smarts: Why do disks and RAID controllers form storage vendors cost so much more?   Because those storage vendors are on the hook for a complete product, and put engineering time into changing the disk behaviour by customizing drive firmware and pre-qualifying drives.   They also know that SMART is a sham, predicting only a small fraction of disk failures.  The secret sauce is performing advanced failure profiling on the RAID controller, and coordinating it with fully understood and tuned drive firmware.  This is the true difference between your cheapo Promise variety RAID setups and those from Netapp, Hitachi, EMC and HP.
  • Drive failure rates do go up with age: Heavily used drives are either going to fail in the first three months,  or with steadily increasing risk beyond the 3 year mark.    We’ve seen this in the field as well,  even early $1000/drive 300GB FC disks had a 10% failure rate in the first 3 months after you started working them hard.   Drives older than 3 years have typically been spinning, without stopping, for that entire time period.   Bad Things are known to happen when you spin them down, let them cool, and then try to spin them up again.
  • Background media scanning is the best way to detect drive failures: Does your RAID controller perform background media scanning or at least a full array consistency check on a regular basis?  Great!   Because THIS is the real way to predict disk failure,  by monitoring and trending subtle disk failures (bad sectors, etc),  rather than waiting for SMART to (not) predict a major mechanical failure.   As it was said above,  SMART is mostly useless.   Hopefully you’re not feeling quite so good about that “S.M.A.R.T. Status OK” message anymore.
  • RAID 5 is more harmful than you think: Many numbers are starting to come out about how often double failures are happening in RAID5 arrays.  It’s quite disturbing, but you run a HUGE risk of data loss during that high-activity array rebuild after your first disk has failed.   And, as pointed out, too many people rely on RAID5 as a backup solution.  So let’s say it again RAID5 is NOT a backup solution, and never will be.

ASP and ASP.NET: Still easy targets for SQL injection

Posted by Irving Popovetsky on June 25th, 2008

Microsoft has released a security advisory (954462) warning users that automated SQL injection attacks against ASP and ASP.NET based sites are escalating.  Unlike about 5 years ago, most web developers I talk to today understand what SQL injection is and how to defend against it.

The new automated attacks are mostly focused on Content Management System (CMS) functionality, in order to insert an IFRAME on your website pointing to a malicious site.  5 years ago we all talked about how SQL injection attacks would focus on stealing credit card numbers and personal information directly out of databases, or skipping password checks or adding administrative users.   I demonstrated that last one myself during a security engagement.   The attacks were jaw-dropping and scary, and we thought that everyone was on the way to getting it fixed.

If you find this XKCD comic funny, you’re halfway toward understanding exactly how dangerous SQL injection is:

XKCD

So why are ASP and ASP.NET still such easy pickings?   I believe it’s due to two main reasons:

1.  ASP has THE WORST string validation functionality of any modern programming language used to create web applications today.

Have you ever seen a successful, tight form validation routine written in ASP or VB?   It’s ugly, and easy to get wrong.    This is because there’s no regex (regular expression) library for performing string-fu,  a luxury that pretty much everyone else has.

5-6 years ago, smart developers realized this and quickly said “Hey, we need to filter this garbage before it ever gets to the app, by building ISAPI filters in C and C++”.   Some shops wrote their own, many adopted tools like Microsoft’s URLScan or Eye’s SecureIIS.   Problems were solved, as these ISAPI filters magically denied all sorts of nasty strings, and were totally worth the pain of implementation.

2.  Microsoft left Windows 2003/IIS 6 users out in the cold

Right around the time when Windows 2003 shipped, two things were happening.  First, people like myself were finding MAJOR functionality flaws in URLScan which Microsoft was basically refusing to fix, and telling users to wait for the next version.    Second, instead of actually shipping that next version, Microsoft proclaimed that IIS 6 had “URLScan technology” built in, and nobody needed URLscan anymore.  Too bad that whatever was actually included with IIS 6 was missing URLScan’s best functionality, including the malicious string denial functionality.  Thanks for that one, Microsoft.

So for about 5 years, the memory of URLScan faded, and everyone migrated to Windows 2003 and IIS 6.  Sure, IIS 6 is a lot more “secure by default”, but ASP shops weren’t being adequately protected from SQL injection attacks.    It wasn’t until THIS MONTH that Microsoft released URLScan 3.0 Beta which finally supported IIS 6.   URLScan 3.0 Beta also supports IIS 7, which now has basic request filtering, but not as advanced as URLScan.   It is not too late to consider this tool.

3.  Some ASP and ASP.NET shops are still running insecure code and using insecure coding practices

Microsoft and various security firms have been preaching advice about how to protect against SQL injection attacks for years now.  It is a lack of risk awareness and training that is allowing it to continue.   The argument that it is just too expensive for a business to fix these vulnerabilities doesn’t stand anymore, the attacks are too damaging.

What can be done?

The answer is simple.  You need to self-assess your applications, or find someone to perform the assessment for you.   Be careful, though, self-assessment has a huge risk, which is a golden rule of security:  The designer of a system is the least likely to see its flaws.   Fortunately, if you go this route there are plenty of free and intuitive tools to help you along the way.

HP has released a cool new tool called Scrawlr (free download) that will walk your ASP/ASP.NET/MS SQL based website and search for basic SQL Injection vulnerabilities.   Unfortunately the tool does have some serious limitations  (doesn’t handle authentication, won’t check forms or anything involving a POST, and cannot perform blind SQL injection).   But it is a nicely packaged tool for finding the simplest vulnerabilities, the ones that the bad guys are hitting as well.

Fortunately, there are plenty of other free tools that perform Blind SQL injection (check google),  as well as WebScarab and even the Firefox add-ons TamperData and Hackbar to assist you in self-assessing your own site.

Adventures with Windows Server 2008

Posted by Amber Pham on June 13th, 2008

Early this year, I pulled the Windows Server 2008 Feature Components and Active Directory posters out of TechNet Magazine and hung them up over my desk. I then excitedly installed Windows Server 2008 on my test server using my TechNet subscription. I was eager to try out the many enhanced features of Microsoft’s new server OS before they reached wide use. One of the most promising features added to this server OS was built-in virtualization (available on x64 systems only). In order to do my daily troubleshooting and research, I need several OS instances and builds available, such as Windows Server 2003, a separate server with MS SQL installed, and SUSE Linux running a nagios monitoring server. Other than Hyper-V, I was also interested to try out the improvements made to Active Directory, such as the restartable AD service.

The first thing I noticed after building up the new server was the Server Manager screen that greets the administrative user on logon. I was impressed with the array of features that can be managed from this console as well as the breadth of the information about each feature that was presented. For instance, after installing DNS, the DNS service information and relevant event logs appear under the DNS feature in the Server Manager console.

The next thing that I noticed was that the new server would not reboot – it would simply hang on shutdown at a black screen interminably. At first, I thought this was the long shut down time that I was warned about. Apparently, there have been improvements made to the shutdown process that reduce the chances of file corruption due to services that fail to shut down completely before the allotted shutdown timeout period.

After a little research, I discovered that several devices drivers could not be found, including the one for ACPI. This meant that I had to be physically present to restart the computer after software updates and OS configuration changes. The test server that I’m using is an off-brand grey box, whereas major manufacturers like HP and Dell have probably already worked out any major driver kinks by this time. However, driver support is something to keep in mind.

After configuring a DNS server on the 2008 box, I installed Active Directory. As promised, the AD process runs as a service that can be stopped and restarted. This is convenient if you need to perform offline operations on a DC. As I explored around the AD tools, I noticed that GPMC was installed by default, so I didn’t have to download and install a toolkit to use it.

Once Active Directory was installed and running, I turned to the biggest new feature in Server 2008 – Hyper-V virtualization. Because it was early in the release cycle, only Hyper-V RC0 was available. Right away it was apparent that it was a 1.0 technology. Hyper-V only supported a few operating systems, and getting those few installed was far more laborious than on the other virtualization system that I’ve used. Many people have expressed interest in this technology, as it promises to save licensing money on virtualization. Stay tuned for an upcoming entry on Hyper-V, because the topic deserves a separate treatment. In the meantime, I recommend holding off for some basic features that are still missing.

Shortly after I had my test server configured just the way I needed to be productive, my activation grace period ran out. I attempted to activate my instance of Windows, but I received a message that the DNS server could not be contacted. I thought this was strange, since the server was a DNS server, and it could contact Microsoft without a problem. Once the grace period expires, basic Windows functions are no longer available, such as updating device drivers automatically. I could have reset the activation period for another 240 days, but this would only be putting off the inevitable.

After extensive searching, I found a Microsoft article that described the problem: “Activation Error: Code 0x8007232b DNS Name does not exist.” According to this article, my options were: a) set up a Key Management Server (KMS), b) use a Multiple Activation Key (MAK), or c) use the license key. Since this was a TechNet-distributed version of Windows, the TechNet site insisted that I did not need a key, and no key was made available. This only left the option of creating a KMS. To prepare for this, I began reading the extensive “Volume Activation 2.0 Resources for Windows Vista and Windows Server 2008.” It was here I discovered that until five instances of Vista and Server 2008 on unique hardware on your network made activation requests of the KMS, no requests would be approved. Here I was stuck, since I did not have five unique computers on which I could install Vista or 2008, just to get my test server activated. It seems that small businesses using TechNet for testing fell through the cracks of Microsoft’s new licensing plan.

After six months of using Windows Server 2008 on my testing server, I concluded that the OS is not mature enough to be worth the trouble of keeping it going in my situation. I do encourage others to try it out in a testing environment to familiarize themselves with some of the nascent features. I’ve rebuilt my test server with Windows Server 2003, and I’ll continue testing Windows Server 2008 as a virtual machine. I look forward to exploring and writing about the greatly improved performance logging capabilities, the new application virtualization feature in Terminal Services, and Hyper-V. Check back for more articles on these topics in the coming weeks. Meanwhile, the Server 2008 posters will continue to hang optimistically over my monitor.