Tag Archive for 'Windows'

Outlook Inbox shows under Deleted Items folder

Last week I mentioned a bizarre problem that occurred during an Exchange 2000 to 2003 migration for a client. Shortly after posting that little expository, I discovered another.

The customer called to indicate one of his user’s Inbox had been moved to his Deleted Items folder. I had never before seen this, as Outlook prevents users from making such “mistakes” with special folders. I’d heard rumors that previous versions of OWA would allow users to do this, however he insisted that it just appeared this way after the migration. What was really strange was that new email continued to be delivered to this seemingly “deleted” inbox. No attempt to move the folder back to the root of his mailbox would work, and Google turned up little helpful information this time. Deleting the Outlook profile and all of its offline cache goodies proved futile, and I was on the verge exporting his mailbox to a PST file and nuking it, when The Google finally answered.

Turns out some random bloke on a Technet message board had this problem when moving users from Exchange 2003 to 2007, and after some of the same steps I had taken, he had found the solution that worked equally well for me. Moving the user back to the old server, then back AGAIN to the new server put the Inbox back where it belonged. While I don’t understand the root cause of this problem, I’m glad to have solved it without the pains of nuking a mailbox. Just further proves that keeping an old Exchange server around for a few weeks after its migration is a Smart Move™.

Exchange 2003 Migration Pains

I migrated a client from SBS/Exchange 2000 to Exchange 2003 this weekend. On the server-side, everything went quite smooth, despite my fears that SBS would really screw with my ability to work with the standard Windows and Exchange tools. Not so much on the client side.

All the clients were running Outlook 2003. Some users were seeing duplicates of many of their system-level folders (Inbox, Calendar, etc). All users were unable to access any folder but their Inbox. Trying to view the calendar, contacts, or even a user-created mail folder would cause Outlook to crash. I suspected it had something to do with offline folder files, although deleting the Outlook profile and it’s associated OST files had no affect. A bit of Googling finally turned up this post at joeware, which pointed to this post in the Microsoft newsgroups, which contained the answer.

After some work, we were able to determine why Outlook 2003 crashes after moving mailboxes off of Exchange 2000 onto Exchange 2003. The fix is to add a registry value “Guid-Replid Caching” under HKLM\System\CurrentControlSet\Services\MSExchangeIS\SERVERNAME. Under each mailbox store we added a REG_DWORD of “Guid-Replid Caching” with a value of 0.

Taking their advice, I made the change, restarted the Exchange IS service, and damn if that didn’t solve the problem.

Printer server woes

I’ve spent the last several weeks fighting problem after problem at Key, so I’ve decided to blog about them (in reverse order) as a form of therapy. This is kind of long, but I don’t give a crap.

Today’s problem started first thing (gotta love that). Last night (mistake #1) I migrated all of our printer shares to a new server (well, VM), did some testing against the printer in my office (mistake #2), and finally modified the logon script to point all of the users (mistake #3) to the new server. I knew something was up when my Blackberry went nuts around 7:45 this morning while on Rt 2. Sure enough, almost no one could print. Once I got in the office, I swung everyone back to the old print server and spent most of the rest of the day troubleshooting what the hell was happening.

When a Windows client connects to a printer shared off another Windows computer, typically Windows Server, the spooler service on the client initates an automatic download of that printer’s driver off the server. This typically goes off without a hitch, but occasionally problems can arise when the driver being downloaded is a third-party driver or is a kernel-mode driver. Through some trial and error, I determined that printer drivers were not being installed when connecting to the new server, but I couldn’t figure out why. These same drivers (so I assumed) were being installed off the old server, so why wasn’t this server working? I’ve had the typical group policy settings required for this to work set for years.

I have yet to find a solid answer for what was going on, but I have two theories and one resolution.

Theory one: I found this in a Microsoft newsgroup posting from last year.

The default state, unconfigured, allows workstations to add a printer connection to any print server in the same AD forest. This policy applies to XP SP1 and later (I believe). In order for the desktop to comply with this policy, it must confirm that the print server is indeed in the same forest as the workstation. Apparently, it can only do this if it can find the print server via its machine object in AD.

This new print server is a domain controller running under VMware ESX. We’re a one site, one domain, one forest shop, so it stands to reason that the client should see the DC in the forest no problem. However, virtual machines have a way of complicating things, particularly with time syncronization (which I did address per VMware’s docs). Kerberos is typically used to verify a machine exists in the same forest, and of course if the time between the client and the server is off by more than 5 minutes, Kerberos authentication will fail. I’m not convinced that this was the problem, in fact I’m pretty sure it wasn’t. However, to be on the safe side, I followed step 3 in MS KB888046 to disable the forest check for “Point and Print”.

Theory two: The driver wasn’t being installed because of a version conflict or other permissions issue.
Remeber how I said I assumed the new server used the same driver version as the old? Yeah, that wasn’t the case. I had downloaded the most recent driver version off the Kyocera website for these printers and used that on the new server, assuming it was used on the old server. Turns out there’s actually a newer version on the CD that came with most of the printers, and that’s what was used to install these new printers a few weeks ago (no, I didn’t do the installs). Since the new server was using an older version of the same driver, its entirelly possible that during the connection attempt, the driver wasn’t downloading because it refused to overwrite a newer version that was already installed. Alternatively, it’s possible the client never bothered to download the driver from the server, since it already had it, but the versions were incompatible and thus didn’t work. In either case, it seems like this was the true issue.

Resolution: Pre-install the printer driver.
Windows 2000 introduced a great little file called printui.dll. This file, when run via rundll32.exe, allows you to script various printer tasks that normally would require a GUI. One of those tasks is installing a printer driver without a printer. This, combined with an Altiris Software Delivery Job, saved my day. I updated the driver on the new server with this most recent CD version, copied said CD version to my DFS netinstall share, and set up an Altiris job to copy down the driver and install it using printui.dll on all of my client machines. Presto, all connections to the new print server worked like a champ.

Remember those three mistakes I pointed out above? Let’s address them one at a time.

Mistake #1: Last night…
Never, ever, ever, make a change as wide-reaching and client facing as a printer server move late at night when you’re tired, working in your PJs at home, and have had several glasses of wine.

Mistake #2: …did some testing against (my) printer…
My printer is one of the only Dell’s left on campus. Practically everyone else is using a Kyocera printer, which are all brand new and all use the same basic driver. So why the hell wouldn’t I AT LEAST test against ONE of the Kyocera printers? See mistake #1.

Mistake #3: …point(ed) all of the users…
If there’s one thing I can never seem to learn, its to test against a control group. I was so eager to get this long-standing project off my plate I went ahead and pulled the trigger, moving THE ENTIRE CAMPUS to the new print server immediately after putting it into production with minimal testing and maximum inebriation. Dumbass.

So, now that I think I’ve solved the problem, I’ve pointed a few departments (all my non-screamers) at the new server and we’ll see how it goes. I’m also going to keep a very close eye on this server’s DC duties, just in case theory one proves true. The last thing I want is a Kerberos issue on a DC. And, for those of you in the back of the room shaking your head at the thought of a DC acting as a print server, get over it. My DC’s are low-volume machines that are wasted not doing something else. Yes, it’s a VM, but Windows licenses aren’t exactly free either.

A way out of roaming profile hell?

I’ve spent years dealing with Window’s roaming profiles, a feature that allows users on a Microsoft NT 4 or Active Directory domain to have their settings and files follow them from computer to computer. A good portion of my teachers roam in that fashion, necessitating roaming profiles (they make backing things up easy too). Over the years I like to think that I’ve tuned them as best I can, yet they remain slow, cumbersome, and easily corrupted. I redirected the Application Data folder, which speeds logon times, yet puts a pretty heavy strain on the network and file server. I don’t cache roaming profiles, as caching can often bloat or corrupt profiles, yet it lengthens the logon time (seemingly undoing the advantages of folder redirection). I excluded the Recent folder, which also speeds logon times, yet causes teachers to complain about not being to find their “documents” (sigh). I had resigned myself to just living with them, as had my teachers. However, I think I may have found a light at the end of the tunnel.

In doing research on setting up profiles for my new terminal server (yeah baby!), I found a nice little freeware product called the Flex Profile Kit (FPK). It’s a compilation of scripts and the Office 2003 profile wizard which allows you to use mandatory profiles yet still retain custom settings and files. Mandatory profiles are an admin’s dream, but a user’s nightmare. They load fast and are incorruptable, yet they don’t retain user settings. The FPK gets around this conundrum by exporting registry keys (and optionally files) to an OPS file during the logoff process. During login, once the mandatory profile is loaded, the OPS file is loaded back into the profile by way of a login script. What to save and reload are defined by way of simple INI files, and there’s even a GUI to help automate the configuration and creation of the INI files. Deployment is handled by an MSI file, easily pushed out via group policy or Altiris. All of this is free of charge and well documented. Frankly, I’m amazed.

While the FPK was designed to solve profile problems in terminal server or Citrix environments, it’s perfectly usable in a traditional client/server environment like ours. If it works even remotely the way it seems to, I think I may have finally found the way out of my profile hell.

ISA Server and slow SSL

Over the last 4 months I’ve been attempting to track down and solve a problem with ISA Server and an SSL web service we were using. Initial access to the site was fine, but about 3 or 4 pages in, access would become painfully slow and page elements or entire pages would fail to load. This problem was most evident in Internet Explorer, but would also appear in Firefox. It was also most visible on this one particular web service we use, but at times showed up on many other SSL-enabled sites. Last Monday I finally figured out what was happening and solved the problem. It was right in my face the whole time.
Continue reading ‘ISA Server and slow SSL’

Exchange 2003 address lists, circa 1994

I spent about 2 hours on Friday trying to tweak the address lists that show up in Outlook at work. I initially thought this would be simple. One list for faculty/staff, pulled from a couple of OUs, and one list for students, pulled from another OU. Much to my dismay, I quickly discovered that you can’t use OUs as a basis for address list membership. Okay, kind of annoying, but I can live with this. I’ll just search on a few fields and be done with it. Oh, if only it were that simple.

An Exchange 2003 address list is dynamically created from an LDAP lookup you compose using the Exchange System Manager. However, this is a very, very limited LDAP lookup. You must form your queries using AND statements; other forms of boolean logic, including ORs or NOTs, are not allowed. To make matters worse, you have to compose your field search seperately for users, groups, and query-based distribution lists. So, I can’t create an address list that includes both users and mail-enabled groups with the word “faculty” in the description. It seems the description field of a user is different from the description attribute of a group. If I create a search that looks for a user description of “faculty” and a group description of “faculty”, I’ll get no results. Since Exchange is AND-ing my terms together, and since a user can’t contain a group attribute or visa-versa, my search will NEVER be valid.

This reminds me of a web search engine from 1994. Then, when WebCrawler came out, remember how cool it was that you could do very complex boolean-logic searches? Soon after Altavista appeared, and then we could use things like NEAR or WITHIN to further expand our searches. A few years later, Google apepared at Stanford and took searches to another level. Are you noticing a forward-moving trend here?

It seems the Exchange team has taken a step or two backwards.