Blog: SBS 2008

After a software update on a 2008 SBS Server, we encountered a problem with the Quickbooks installation. What used to work with Quickbooks now showed an error message that there was a problem verifying the program’s signature.

Viewing the executable’s properties and looking at the Digital Signatures tab, it showed an error with the signature verification there too. I checked to executable from a 2008 R2 remote desktop server and the digital signature tab showed no problems.  Looking through the folder’s previous version for the executable from before the upgrade, it was observed that it was signed with SHA-1.  The new file was signed with SHA-256.

I was able to find the following information about code signing and 2008 SBS does not support SHA-256 signing.   https://social.technet.microsoft.com/wiki/contents/articles/31296.implementing-sha-2-in-active-directory-certificate-services.aspx .  The software vendor was notified and said they’d work on signing with SHA-1 again on next release.


 

I have done a couple SBS 2003 to SBS 2008 migrations in the past and because the customers were relatively small with less than 20 users, we opted to just build the new SBS 2008 server with a completely new domain and then migrate the data. We would recreate all the user accounts, mailboxes, and shares and choose a maintenance window to do the switchover. It works fine for companies with low complexity and downtime flexibility. However, I just started an SBS 2003 to SBS 2008 migration for a company that operates pretty much 24-7 and they have a fairly high complexity level on the application side.

I have tried some of the SBS 2000 -> SBS 2003 migration tools and they were pretty pathetic, but I had to have an easier way for this migration. After some research, I came across a set of processes that you can use to migrate SBS 2003 -> SBS 2008. They are documented pretty well by Microsoft here: http://www.microsoft.com/downloads/details.aspx?FamilyID=52b7ea63-78af-4a96-811e-284f5c1de13b&displaylang=en.  The process is pretty tedious...I won’t get into it here. You can read the doc if you are interested.

The gotcha is what I encountered during the migration install. [more]When you provide the unattended install file for the SBS 2008 install, first it goes through and installs the OS. After a reboot, it starts the actual migration process. I was watching closely and noticed that it seemed to hang at about 20%. I looked at the event logs on both ends and couldn’t find anything then after some a search on Google I found a user blog that mentioned accessing the sbssetup.log file via file share during the install. I checked it out and it indicated that the new SBS server could not find a server in its AD site to replicate with. I reviewed AD sites and services and noticed that there was no subnet associated with the current default AD site. I added the subnet and waited a few minutes and the progress began to move forward…yeah success!

No so fast. It move about 10% and stalled again. Again after looking in the log file, it was an AD replication problem. This time the SBS 2003 server had a sysvol replication journal wrap problem. I found the MS article on how to fix it and applied the registry fix and restarted NTFRS. Again, progress.

The migration ran for another 3 hours and stopped about 95%. Another log reviewed showed the problem was DHCP related. I connected remotely to the DHCP service and I could see that the scope was getting created and the server options were set, but the reservations were not there. I started reviewing those thinking there might be something there holding it up. By accident, I found that one of the MAC addresses in one of the reservations had a trailing space following the MAC. I removed that reservation and after a short wait, the migration continued and finally finished….6 ½ hours later.

So two things. 1. Watch the log file 2. Get lucky


 

I was recently configuring an ISA server for a network support customer including automatic configuration using WPAD.  The customer had a 2008 SBS server and a 2003 ISA server (running ISA 2006).  I added a "wpad" alias (CNAME) to the DNS server on the SBS box to allow clients to automatically detect the new ISA server.  However, when I tried to resolve the entry on the SBS server as well as other hosts on the network, it never would resolve.  I tried other CNAME entries on the server, and they all worked fine.  I tried removing the entry and reading it, but got the same behavior.  I decided to let it sit overnight to see if it was a timing issue.  The next day, I still couldn’t resolve "wpad" or "wpad.bofc.local".  I started digging and found that the DNS service on Windows Server 2008 has a built-in "block list" for some potentially dangerous DNS names.  The default list includes "wpad" and "isatap".  Gotcha!  Since I wasn’t concerned with blocking any DNS names, I decided to turn off the "block list".  I used the following dnscmd command: [more]

dnscmd /config /enableglobalqueryblocklist 0

Other helpful commands when dealing with this include (from http://technet.microsoft.com/en-us/library/cc995158.aspx):

To check whether the global query block is enabled, type the following:
dnscmd /info /enableglobalqueryblocklist

To display the host names in the current block list, type the following:
dnscmd /info /globalqueryblocklist

To disable the block list and ensure that the DNS Server service does not ignore queries for names in the block list, type the following:
dnscmd /config /enableglobalqueryblocklist 0

To enable the block list and ensure that the DNS Server service ignores queries for names in the block list, type the following:
dnscmd /config /enableglobalqueryblocklist 0

To remove all names from the block list, type the following:
dnscmd /config /globalqueryblocklist

To replace the current block list with a list of the names that you specify, type the following:
dnscmd /config /globalqueryblocklist name [name]…


 

I am doing an SBS 2008 install at a customer and have run into the whole x86 / x64 print driver problem. The SBS box is x64 and that is where I wanted to install the network printers. The terminal server is x86. I did some research on the driver compatibility and universal printer drivers and decided for simplicity sake to use the HP universal print driver. I got everything installed, but during testing a couple of the printers (specifically the HP 4050 series LaserJet), I had a very weird problem come up. Every time I printed something, the printer would display “waiting on manual feed tray” as if the job was specifically targeting that tray. Even when I statically set the default tray in the driver config, it would try to pull from the manual feed tray….ahh the joy of printers. Well, after about an hour of troubleshooting, I tried changing what seemed like a very unrelated setting. [more]

Notice the Paper type is unspecified. By default that is set to "HP Tough Paper" on this model of printer. If that setting is not changed, it defaults back to the manual feed tray NO MATTER WHAT. Does the gremlin in the printer know what type of paper is loaded…well, apparently so. Do yourself an favor and set it to “Unspecified”.