Circuit Rider
Version 3.3

By Jim Scheef

Last month, I mentioned the DACS Library and promised more information later. I meant later in that column, but age is creeping in… So now, before I forget again, here’s the story. Several years ago we were given some bookcases for the Resource Center. After a significant period of time, I got tired of looking at these empty bookcases and suggested that we start a DACS Book Trading Library. Here’s how it works: When you have computer books that you can no longer fit on your bookshelves, you bring them down to the Resource Center and put them in the bookcases. When you get home, you can tell your wife that you got rid of those old computer books, for which will you will score many points. These books are now available to all DACS members. When you come to the Resource Center for a SIG meeting, take a quick glance at the bookcases. If you see something interesting, take it and it’s yours. This is not a lending library – there are no checkouts or due dates. Keep the book forever or return it when it no longer fits on your bookshelf.

Every so often, someone (probably me) will look through the library and weed out the junk that no one will ever want. Given that one man’s junk is another’s treasure, this means that I might be throwing away the very book for which you have been searching for months. Don’t let this happen; come to a SIG meeting and look through the library. The SIG meeting is just another bonus!

DACS Website Committee
Have you visited the DACS web site recently? The web site redesign is on the air! Anna Collens did the design with input from “the committee” on the menus. Sean Henderson found and debugged the calendar, making it work with cascading style sheets (CSS) so it fits in with the new design. Jeff Setaro helped integrate the new design into the old content. And Scott Preston has been right there all along, keeping the web site current and planning for the ongoing maintenance. My role has been to provide encouragement.

So far, the “front end” is complete with menus leading to strategic points in the old content. The calendar is now dynamic, so updates are as easy as editing a text file. We redesigned the SIG pages to provide more information, while making it easier for the SIG leaders to update this content.

Over the years, the DACS web site has accumulated a lot of content (about 50M). Each month all of the dacs.doc articles written by DACS members are added to the web site in HTML format so they are easier to read online. This is in addition to providing a complete PDF version of each issue. All of these “legacy” pages need to be converted to the new format. I’m hoping that much of this work can be automated, but we have yet to test this out.

I think the new web site is fabulous, and I hope you do, too. All this happened so quickly, it just blows me away!

Home Network Upgrade
Previously on Home Network Upgrade: Last month, I explained why I needed to upgrade from Exchange Server 5.5 to the 2003 version. Over a period of way too many months, I purchased a new server, installed Windows Server 2003, and made this machine the domain controller on the network. After that I studied books, magazines and the Microsoft Knowledge Base (KB). In fact I sat down and compared the procedures in Mastering Microsoft Exchange Server 2003 to the KB document, “Exchange Server Deployment Guide.” Both sources had basically the same steps. Keep in mind that studying books and magazines like this can be a really good way to procrastinate!

Strange as it might seem, the first step was to run a series of tests that would prove that the network was, indeed, ready to run the new version of Exchange Server. Taking a brief step back, let me explain that Exchange 2003 is not a stand-alone product like Version 5.5 was. When Microsoft introduced Windows 2000 with Active Directory (AD), they took the directory of people and their e-mail addresses out of Exchange 5.5 and moved this functionality into Active Directory. So Exchange 2003 does not have a directory of its own; it requires the directory that is already available in Windows Server – Active Directory. Thus Exchange 2003 will not function unless AD is installed and working correctly. This, in turn, means that your DNS servers must support the special functions required by AD and so on, and so on.

As we’ll see later, AD is more than just people and email addresses. It also contains objects like computers, printers, and references to certain special programs (mostly from Microsoft). This brings some neat features to a network, like when you need to print something; you can search in the directory for a printer near your current location. Windows will then install any drivers you need and print the document. Cool, eh?

So I started running the required test programs. The first test ran with good results, but I could not get the second battery of tests to run at all. I hate to say that I gave up so easily but it was time to call Microsoft. The errors I was getting made no sense at all and I was totally stumped. It was 5:30pm on a Friday. A cheery young woman answered the Microsoft help number after I waded through only two layers of voice prompts. After explaining that I was an MSDN (Microsoft Developer Network) customer and that I wanted to use one of the four “support incidents” that are included with the MSDN Universal package, she routed my call to the “next available Exchange support engineer”. Most of you know that several years ago Microsoft moved their first-level support to call centers in India. I’ve had fairly good experiences with Microsoft support, even in India. My support engineer introduced himself as Vikram. I had no trouble understanding his English so long as he didn’t speak too fast.

After describing my goal (migrate to Exchange 2003) and symptom (the tests were failing in weird ways), Vikram immediately asked that I check the permissions on the account I was using. These were permissions within Exchange 5.5, not network permissions, and there was no mention in any of the books or KB articles. Once these permissions were corrected, the tests ran perfectly and I was ready to begin the actual migration process. If I had an employer to pay the cost of this call, I might have hung up right then feeling that I had received full value for the call.

Now, since I paid for my MSDN subscription out of my own pocket, I wanted to extract as much from this “support incident” as possible. Something I have learned over the years with any pay as you go support organization like Microsoft is to define the problem as broadly as possible. If I had said that my problem was that the tests would not run, my support incident would be complete. Vikram would have said “Thank you very much and have a very nice day,” and hung up. Instead, he started to lead me through the entire migration.

The first real step was to install something called the Active Directory Connector. This ‘connects’ AD to the directory in Exchange 5.5. AD is really the hub of a Windows network. The connector lets you synchronize the directory in Exchange 5.5 with AD for the domain. In a real company with thousands of users, this is a big step that will take some time to complete – both in terms of computer running time and the administrative time to resolve any accounts that don’t match up. Of course, in my situation there is only one real user (me) plus a few accounts that I’ve set up for testing over the years. The synchronization process goes so fast, Vikram doesn’t have any time to take a break.

Now we get to actually install Exchange Server 2003. Once again, Vikram walks me through the process without a hitch. The install takes about half an hour, even on my dual-processor server. I grab a couple of cookies (the baked kind) and Vikram gets his break. When the install completes, we run some checks to be sure it was successful and proceed to moving the mailboxes. Just to be safe, I moved a couple of the test mailboxes. These were successful, so I could be reasonably certain that my mailbox will also move ok. Since my mailbox is a little under a gigabyte, we put that off and moved on to the next steps in the migration.

Our next task was to install Outlook Web Access (OWA). This really cool facility is web-based email for Exchange. This is what I use when traveling (or at my girlfriend’s house) to access my business email. Exchange 2003 OWA is so good, you have to look twice to see that you’re just using a browser. It even works quite well in Firefox and Navigator 7+. Unfortunately, it did not work right out of the box on my server, and this is where Vikram started to call in the troops. First was Haresh, an Internet Information Server specialist. He walked – actually, he spoke so fast that he ran me through the process of reinstalling and reconfiguring IIS. I already had IIS installed and it seemed to be working (it passed the tests, remember?) but OWA failed miserably. So it was now time to call in the second-level support for Exchange. After a few minutes, we had Mary on the line – a very pleasant woman in Toronto, Canada, who actually preferred to work nights.

Mary recognized that the problem in both IIS and OWA was that my Exchange server was also the domain controller. Domain controllers impose certain limitations on IIS because there are no local user accounts. A local user account is a user who is defined on a single machine rather than within AD for the domain. Your user id on your Windows XP machine is undoubtedly a local user account, unless you connect your machine to the network where you work. Local user accounts would be a huge security hole on a domain controller, so they are totally disabled by the AD installation process. Over the next few hours, Mary took me through a long series of steps to do manually what the install script could have done in a few seconds. As we added or corrected many permissions and security settings, we gradually fixed IIS so that ASP (Active Server Pages) and ASP.NET worked correctly and this resolved the problems in OWA.

Like all second-level support people, Mary really knew her stuff. As the hour got later and later, Mary gave me several KB articles that gave additional details on most of the remaining steps in the migration. In addition to moving the mailboxes, I needed to move the public folders. Microsoft has always talked about the collaboration features of Exchange Server in their efforts to compete with Lotus Notes and Novell GroupWise, the other major enterprise-grade “groupware” products. Public folders are the key to any collaboration “features” and as such, Exchange replicates these folders to all of the Exchange servers in an organization. This replication process is designed to get the job done while using as little network bandwidth as possible. So, by design, it runs when the network is less busy. Remember, most Exchange installations are “considerably” larger than mine [heavy understatement implied here]. Moving public folders uses this replication facility rather than something special as with the mailboxes. While I had Mary on the line, I tried to replicate a small public folder to be sure I had it working. It would take me several days to replicate every public folder and then remove the folders from the old server, and I don’t really have that many. I can see where this could take weeks in a large organization with servers spread out all over the country or around the world.

At 3am Saturday morning, I finally called a halt to our efforts and hung up the phone. This marathon call had lasted nine hours. The new Exchange installation was sending and receiving mail and OWA was working with only a couple of issues; but there was still much to do. Before saying goodbye to Mary and Vikram, I made sure that I had the incident number and that the incident would remain open until the new server was fully operational. Next month, we’ll see how we cleared up the last few problems, some of which I had yet to find!

I hope you’ve enjoyed this time between ski seasons. What’s it called? Summer?


 
 
© Danbury Area Computer Society, Inc. All Rights Reserved.
Web Site Terms & Conditions of Use