Lessons Learned

And here you were thinking that your Mac would be immune to the DST problems that seem to be plaguing the rest of the US. Well, not necessarily. Turns out that Microsoft has included updates in Office Update 11.3.3 for Entourage that handles issues related to calendar items and the new DST rules. And if you’re only using Entourage 2004 for POP3 or IMAP accounts, you’re probably going to be OK. But only if you install Update 11.3.3 (at least according to KB924606).

But, if you’re using Entourage 2004 to connect to an Exchange server, your calendar may just get a little funky for a little while. According to a blog post from the MS Higher Education West group, if the Exchange server has not been updated with the patches to fix the DST issue. Where can I learn about these updates, you may be asking? Well, this Microsoft page has information, and http://www.dstpatch.com/ also has update information.

Bottom line, the patch for Exchange is out, but not necessarily universally installed. The Entourage patch is out, as is the OS update from Apple that allows the core Mac OS to handle the new DST laws. But the Outlook patch is not yet available, so expect that until all three players are updated in a particular location there will be some discrepancies about meetings that are scheduled after March 11, 2007.

My Mac recommendation: go ahead and update to 11.3.3 for Office for the Mac, but be aware of possible DST meeting hiccups until everyone else gets updates.

I’ve been fighting a rash of internal DHCP issues for clients running ISA 2004 SP2 on SBS 2003. Amy Babinchak noted this a while back in her blog, and I’ve been working with her to iron out the issues. One item I ran across this morning seems to tie the problem to a Restrited Access rule. The jury is still out on the why and the root cause of the issue, but I noted one change that I made to one set of rules that allowed DHCP to work correctly on the internal network afterward.

The rules that had been created followed this pattern: Set of domain URLs that the creator of the rule did not want to allow internal workstations to access; default action on the rule was “deny”; applied to all protocols and all users. In one case, I modified the rules to apply to all protocols except those listed, and I included DHCP Request and DHCP Reply in the exceptions list. Once I applied those changes, DHCP started working internally again.

Granted, these rules were high in the order processing, and if they had been lower in the order list, possibly even behind the Protected Network Access rule, we might not have seen the behavior. But something about the way those rules were created seemed to deny internal workstations access to DHCP.

I still have other sites with DHCP issues that I’ve only been able to get around by following the instructions in Amy’s post. But there has been some rumblings about denied access rules, so we’re starting down that road first to see what’s happening.

I’ll post updates here as I get them. Stay tuned…

Today I was reminded (again) why using the default controller drivers when doing an SBS setup is a Bad Thing. I was rebuilding a server for a client who needed to install an updated RAID controller card. I got the drivers off the CD that came with the controller and copied them to a floppy disk. I booted the server from the installation CD, pressed F6 to tell setup that I had drivers to load, and selected the proper card drivers from the floppy. As setup continued and started copying files to disk, I got an error that it couldn’t copy a particular file. It was a catalog file for the controller driver, and it was apparently not on the floppy. Well, not to be deterred, I restarted setup, pressed F6 again, but this time when it prompted me about the drivers and let me know that the drivers I had on floppy were newer than what setup had on CD, I opted to let setup use the drivers on CD and continue.

Continue it did. Setup got all the way through both the text mode and GUI portions of install and rebooted the system to load the OS for the first time. Then everything went south. I got the Windows 2003 spash screen for about 2 seconds, and the server rebooted. I’ve seen this behavior before (and I’ll document it in a later post or possibly use it as script material for an IT Horror flick) so I knew it was a problem with the controller driver. I went to the manufacturer web site, downloaded the latest driver disk set and used that for a repair install of the server. The repair install completed successfully, and the server booted normally after that.

Out of curiousity, I compared the driver files on CD to the driver files I downloaded from the web site. They were the same, save for one file - the catalog file that setup complained about being unable to copy.

Just goes to show, again, that you should really grab the latest drivers from the controller manufacturer web site before building a server, espcially if you’re working with a “white box” server. I’ve learned my lession. Again…

Every once in a while, I have one of those “well, duh” moments. Today was one. Got an e-mail in a backchannel discussion about an apparent increase in Allocated Memory Alert warnings from SBS Monitoring services, and it reminded me that I have a few servers that I’ve been getting daily alerts from. My take up to this point has been “they don’t seem to be causing any performance problems, so I’ll just look at them later.” So, needless to say, a couple of servers haven’t been looked at in at least a year. Well, not for this alert, anyway.

But later in the e-mail thread, someone pointed out a post on the official SBS Support Blog that discusses the need to change the settings for the allocated memory alert based on the amount of RAM installed in the server. Sure enough, after I read through the post, I noted that all of the servers that have been getting the alert are servers with 2GB of RAM or more.

So, now we’re off to change the Allocated Memory Alert settings as outlined in the post. And as a result, should reduce the amount of mail we’re getting and filtering through every day.

As Susan says, the official SBS Support blog is definitely one to watch. And I for one was guilty of not watching it, so I missed this little gem for about 8 months.