Just another Microsoft MVPs site

Category: 314 (page 1 of 6)

MSKB 961143 fails to install on SBS 2003


So I’m having an exciting Friday night at home catching up on some support tickets, and I have one monitoring ticket for one of my managed SBS 2003 boxes where Microsoft update 961143 fails to install repeatedly.  Normally, whenever I have a patch that fails to install via Kaseya – simply logging in to the device & running Windows Update to install the problem patch resolves the issue.  Yeah – not so much with this one.  Installing the update via Windows Update, or by downloading the update & running it manually – it consistently fails.  Running the install manually, I just get a pop-up saying something vague to the effect that installation failed and click OK to undo changes.  I searched the web, and continually found thread after thread after thread of people having the same issue, but no solution.  Some suggested solutions included verifying the companyweb site was using the default app pool, some saying to check a registry key or two – but nothing worked.

The windowsupdate.log was vague – and the error code it provided (0x8007f070) didn’t help any with my web searches either.  I then dug down and found the individual update installation log (%temp%\QFE73170.log) and reviewed its contents:

2010/05/14 21:33:36    ————————————————————–
2010/05/14 21:33:36    begin installing the fix
2010/05/14 21:33:36    enable kerberos if necessary on companyweb
2010/05/14 21:33:36    the current start type of iis admin service is: 2
2010/05/14 21:33:36    find virtual server id of hostName: companyweb
2010/05/14 21:33:36    iterate through each IISWebServer under IIS://localhost/w3svc
2010/05/14 21:33:36    current server binding: IIS://localhost/w3svc/1,
2010/05/14 21:33:36    current server binding: IIS://localhost/w3svc/1,
2010/05/14 21:33:37    current server binding: IIS://localhost/w3svc/2, :6345:
2010/05/14 21:33:37    current server binding: IIS://localhost/w3svc/3, :8081:
2010/05/14 21:33:37    current server binding: IIS://localhost/w3svc/4,
2010/05/14 21:33:37    found virtual server, server path is: IIS://localhost/w3svc/4/root
2010/05/14 21:33:37    get single property: IIS://localhost/w3svc/4/root,AppPoolID
2010/05/14 21:33:37    get single property successfully
2010/05/14 21:33:37    current virtual server is using app pool: DefaultAppPool
2010/05/14 21:33:37    get single property: IIS://localhost/w3svc/apppools/DefaultAppPool,AppPoolIdentityType
2010/05/14 21:33:37    get single property successfully
2010/05/14 21:33:37    identity of current virtual server’s app pool is: 0
2010/05/14 21:33:37    not using network service to run current virtual server

That last line in the log was the key:  For whatever reason, MSKB 961143 will bomb out if the DefaultAppPool is not using the NETWORK SERVICE identity.  I opened up IIS Admin, expanded <server> | Application Pools.   I right-clicked on DefaultAppPool and selected Properties.  I then went to the Identity tab on the app pool properties page, and sure enough – my DefaultAppPool was running under the LOCAL SYSTEM identity.  I changed the identity from LOCAL SYSTEM to NETWORK SERVICE, and clicked OK to save the changes.  Back in IIS Admin, I right-clicked on the DefaultAppPool again and selected Recycle to stop & restart the app pool.  After recycling the DefaultAppPool, I re-ran the KB 961143 installer and the update installed successfully.

Killing off ISA

Earlier today Susan blogged about upgrade season in her office, and getting ready to migrate from SBS 2003 to 2008.  In that post, she talked about uninstalling ISA and mentioned a post that Kevin has on that subject.  I thought I’d take a moment to expand a little bit on Kevin’s post and add a few thoughts from my own battle scars with removing ISA.

First and foremost – Kevin mentions removing the ISA firewall client from all of your PCs before you remove ISA from the server.  I cannot overstate how crucial this step is.  The ISA 2004 firewall client uninstaller wants access to the original installation MSI, which lives in a share on your SBS box.  This share is actually the Clients folder in the ISA installation directory.  So what happens when you remove ISA from your SBS?  You guessed it – the mspclnt share with the firewall client installation files is removed, which means any firewall clients still installed on PCs are not going to be happy when you try to remove them and they can’t find the MSI.

Since the Clients folder under the ISA installation folder is typically only about 5MB, I copy this folder to a safe spot on the server – usually my Tech directory where we keep various utilities and scripts.  Here’s why – more and more, customers are backing up their workstations whether via Acronis / StorageCraft / Windows Home Server.  We may find ourselves at a point in the not so distant future after removing ISA that we need to restore a PC from an image taken before ISA was removed, and need to remove the firewall client again.  Or we may discover a forgotten PC / laptop that we missed removing the firewall client from.  There’s all sorts of scenarios – but by keeping the Clients folder in-tact, we can share that out with the original mspclnt share name at any time and be able to uninstall the firewall client just like ISA was still installed on the server.  Without the mspclnt share, you have a very VERY ugly path in front of you, and it is safe to say that you may end up facing the decision of living with the firewall client still on the machines, or wiping & re-installing the OS . . .

Second – Kevin also makes a brief mention about proxy settings.  When you uninstall the firewall client from a PC, it will automatically disable proxy settings for the user account that is running the uninstall, but not for any other users on the machine.  So if you have a PC that multiple users log in to, or if you are running a terminal server, be prepared for some proxy pain.  I actually have a little VBScript that disables proxy settings for the current user by changing the value of the HKCU\Software\Microsoft\Windows\CurrentVersion\InternetSettings\ProxyEnable key from 1 to 0.  I modify my login script to call the VBScript, in effect ensuring proxy gets disabled for each user when they log in to each machine.  

The other aspect with proxy settings to keep in mind are your server-side applications.  Unless you modified your ISA firewall policy to allow unauthenticated outbound http access from the server itself, you most likely specified proxy information for apps like Trend Micro’s Worry-Free Business Security or even WSUS – so that they can download their updates automatically.  After removing ISA, you no longer have a proxy server, which means apps configured to use a proxy aren’t going to be able to get out to the internet.  As a result, you stop getting automatic updates for things like A/V.  So you will need to manually update the connection settings in these apps to remove the proxy settings previously defined.

So – here’s my quick checklist for removing ISA from your network & installing a hardware firewall:

  1. Prep your hardware firewall in a lab setting.  Enter in all public IP info, disable DHCP, and create all of our inbound rules.  It’s best to do this while ISA is still installed & working, so you can refer to the rules in ISA to make sure you don’t miss any necessary inbound rules for your environment.
  2. Backup your ISA configuration.  While we’re moving away from ISA permanently, if we do encounter an issue with the new hardware solution where something isn’t working that was working with ISA, the ISA backup is an XML file that is relatively easy to read to see what rules you had and what they did without having to reinstall & restore ISA on your SBS.
  3. Open up your outbound access in ISA by creating the proverbial ALL/ALL/ALL rule.  In other words, create a new access rule in ISA allowing All outbound traffic via all protocols for all users/computers.  Much of the internet access in ISA on SBS is dependent on users being members of the Internet Users security group.  The firewall client on the PCs is what actually passes user info to the ISA server so it can check group membership.  Once we remove the firewall client from PCs, ISA isn’t going to be getting user info and some stuff that worked before isn’t going to work now.  If you only have 5 PCs and are moving from ISA to your hardware firewall on a Sunday when no one is working, you might be able to skip this step.  But if you have a larger number of PCs, etc. this helps to insure you don’t disrupt users’ internet access too much while removing the firewall client . . .
  4. In my case, I update my domain login script to call my DisableProxy.vbs script at this point.
  5. Uninstall the firewall client from ALL PCs.  Again – see my notes above.  Your life will be MUCH simpler if you insure the firewall client is completely removed from all PCs before removing ISA from your server.
  6. Copy the contents of the mspclnt share (%programfiles%\Microsoft ISA Server\Clients by default) to a safe location on the server, and plan to keep this folder safe for some time  [:)]
  7. Follow Kevin’s steps 3-9 to remove ISA from the server.
  8. When you re-run the CEICW, it should automatically update the DHCP scope option on the server to use the internal IP of the new hardware firewall as the default gateway setting.  If you have any devices that are using static IP addresses, you will need to manually update those with the new gateway.  (HINT:  Take a few extra minutes to create DHCP reservations for each device using a static IP, and change those devices to DHCP – so if you have another network reconfiguration in the future, all you have to do is reboot those devices instead of reconfigure [:)].    For all of your other DHCP devices, you will want to run an ipconfig /release followed by an ipconfig /renew to update their IP settings so they pull the new gateway, or you can reboot them as well.  HINT 2 – PSTools are your friend.  Create a batch file with the two ipconfig commands, and use PSExec to push & execute the batch file on all machines in the domain from the server.  5 minutes tops to update the IPConfig on all domain machines (that are online) instead of sneakernetting . . .
  9. ALSO – if you followed Jim Harrison’s steps to configure auto-detection of proxy settings on your SBS LAN, you want to remove the wpad A record from your internal AD domain forward lookup zone in DNS – otherwise you may have devices pulling proxy settings for pointing to your non-existent proxy server via auto-detect.

So that’s my addendum to Kevin’s excellent post


P.S. . . .   and if you haven’t decided on a hardware firewall yet, I highly recommend Calyptix devices.  These are the standard devices we are implementing when migrating customers to SBS 2008.

The View from the Dark Side

I have a confession . . .   I took my first step moving to the dark side three months ago.  You see, my beloved Treo 700w had finally died for the last time – it had lived a long, hard life of just over 2 years and had been dropped countless times.  I was looking for a Windows Mobile 6 device that had a touch-screen and a vertical orientation like the Treo (I for one dislike the slide-out keyboards because it requires two hands to type).  I was surprised at the lack of options available for those three criteria.  As a matter of fact – Verizon did not have a single device that met all three criteria – they still had the Treo 700w with a touch screen, but running WM5.  They had the new Moto Q with WM6 and the vertical orientation, but no touch-screen.  Or the Samsung isomething that had a touch screen and WM6, but had the horizontal slide-out keyboard.

So on a whim, I did an abrupt face and bought myself an iPhone.  This was back in March, and I admit that what finally pushed me over the edge was the announcement of the iPhone 2.0 software update that would include support for push email via Microsoft ExchangeSync.  Admittedly, there are days that I still miss my Treo  (I still prefer a physical keyboard over the iPhone’s on-screen keyboard – but I eventually discovered the trick to fast composition on the iPhone is to just get close and trust its auto-correct to fix your typos – and 98% of the time it gets it right).  The biggest pain over the past 3 and half months has been the lack of over-the-air calendar and contact sync.  After having that for over two years with my Treo, having to dock my iPhone every few days or remember to look at my Outlook calendar before I ran out the door was getting old. 

But anyway, today was d-day – when the iPhone 2.0 upgrade was officially available to the masses.  I didn’t get a chance to really try the upgrade until late this afternoon.  I started earlier this morning, but I could not get iTunes to backup my phone prior to the upgrade (unknown error -43).  Of course, it gave me the option to continue without a backup – I would just lose little things like my text messages, favorites, mail accounts, etc. – basically anything that wasn’t sync’d with my PC.  So I stuck it out and eventually tracked the issue down to iTunes not playing nicely with folder redirection in a domain environment.  My music lives in a redirected folder and syncs ok, so I’m assuming the issue is with a redirected Application Data folder.  But anyway . . . )   So late this afternoon I finally got the phone backed up and initiated the upgrade.  The entire process took about 30 minutes to download, install, restore & activate.  Luckily, I did not run in to the mess this morning where Apple’s activation servers were overwhelmed and couldn’t be contacted, leaving a lot of people with a nicely upgraded phone that could not activate and thus had no service . . .   but again, there’s a reason it’s called the bleeding edge . . . smile_regular

But the big news for me is the Exchange integration.  I removed my previous IMAP account, and set up my Exchange account.  Biggest surprise for me: the iPhone will sync with Exchange over the air if you’re using a self-signed SSL certificate on your SBS / Exchange server.  It complains a bit that it can’t authenticate the certificate when you’re setting up the account, but you can acknowledge the warning and it will start synchronizing.  Naturally, if you select to synchronize your contacts and calendar, any contact & calendar data on the phone itself will be overwritten by data on your Exchange server.  For me this was no big deal as I was manually synchronizing this data anyway. 

I still have to play around a bit, especially with installing some of the new apps, but so far the Exchange integration is working just as I would have expected.  The contacts feature even handles multiple contact folders in your Exchange mailbox very nicely – even additional top-level contacts folders, and even allows you to search the GAL

Anyway, I’m off to go play on the dark side a little more . . .

Using your SQL in SBS R2 Premium as a back-end for WSS 3.0

I have been getting this question a lot recently, so I decided I should probably blog it.

When you install Windows SharePoint Services 3.0 using the published document from Microsoft, Windows SharePoint Services is set up as a stand-alone server.  This configuration results in Microsoft SQL Server Embedded Edition (SSEE) being installed as the SharePoint v3 data source.

For SBS Premium customers who want to use their version of SQL Server as the data store for SharePoint v3, you need to deviate from Microsoft’s published installation document.  Specifically, on page 7 under step 4b select “Front-End Server” instead of “Stand-Alone Server”  This will result in the setup process not installing SSEE on the server. 

When you run the SharePoint Products and Technologies Configuration Wizard after the install finishes, you will be given the option of either joining an existing SharePoint farm, or creating a new farm.  Select to Create a new SharePoint Farm, and you will be able to specify the SQL server instance you want to use as your data store.  The wizard will then complete the SharePoint configuration and you will then be running SharePoint 3.0 with a full SQL data store instead of SSEE.

Companyweb & Sharepoint v3 – Part 1

This is the first in a short series of running Windows Sharepoint Services v3 on your SBS 2003 / R2 server.

First the caveat:  Upgrading and/or running your companyweb site with Windows Sharepoint Services v3 is not supported – neither by Microsoft nor myself.  Just because I’m blogging about it doesn’t mean I’m supporting it.  Microsoft does support installing WSS v3 in parallel with v2 on your SBS – but only supports the companyweb site running as a WSS v2 site.  Microsoft’s official document on installing Windows Sharepoint Services v3 on SBS can be found here

What’s the fuss?

The first thing to talk about is why you want to move up to WSS v3.  Being a long-time Sharepoint junkie, there are some impressive features in v3 that address many of the complaints and wishes we all had with previous versions.  The key items:

Recycle Bin    All most WSS admins can say is FINALLY!  No more juggling with multiple stsadm or smigrate backups to allow for individual item restores.  And when you need to restore, no more needing to restore those backups to parallel sites.  Granted it worked – but was cumbersome and painful.   WSS v3 gives us a dual-layer Recycle Bin.  Each user gets their own Recycle Bin which allows them to easily recover anything they may have deleted (a document, a photo, or even a list item).  In addition to the individual user recycle bins, there is a site-level recycle bin as well.  So even if your users delete something from the site, and then empty their recycle bin only to come to you the next day to ask if there is any way of getting that item back – well now there is.  The administrator can access the site collection recycle bin and restore items that users have deleted even if they have deleted their recycle bin.  This is configurable so you can specify how long you want to keep deleted items in the recycle bin, so you don’t have to manually empty the site collection recycle bin.

Offline Access to Document Libraries     Yes, you read that right.  So you’re finally getting your users to store their documents on your Sharepoint site – but you’ve still got those roaming users who are keeping files on their laptops so they can have access to them anywhwere, even if they don’t have an internet connection.  Well now you can have the best of both worlds.  With Outlook 2007 and WSS v3, you can now keep a copy of your document libraries within Outlook – so your users can have offline access to their Sharepoint files.

Mobile Access.     Do you have users who are out of the office a lot?  Do they have internet-enabled phones?  WSS v3 includes a mobile page format optimized for web-enabled PDA’s & smart phones – which presents an experience somewhat similar to OMA.  Regardless, you can now access your Sharepoint site, including documents and lists right from your phone.  I only migrated our companyweb a few days ago, and I’m already finding myself taking serious advantage of this mobile access on a regular basis.   

Tighter integration with Office.     WSS v3 and Office 2007 are a match made in heaven.  With WSS v2 & Outlook 2003, we could link Sharepoint calendars and contact lists with Outlook.  However, anyone who used this functionality realized this was a one-way connection:  you could only view the calendars and contacts in Outlook.  Any additions or changes had to be made via the Sharepoint web interface.  Not any more – with WSS v3 and Outlook 2007, you have full two-way integration, allowing you to add/edit appointments or contacts from either the Sharepoint web interface OR from within Outlook.  And an added bonus – if you delete a Sharepoint contact or appointment from within Outlook, it actually gets sent to your Recycle Bin within Sharepoint.

Improved Versioning.     WSS v2 allowed us to keep versions of items stored in document libraries.  WSS v3 allows us to keep track of both major & minor versions within document libraries, and even allows us to keep track of versions of list items.  So you can now see version histories within your lists, and just like with document libraries, restore any previous version at any time.

Improved Security.     WSS v3 gives us true item-level security on documents and even list items.  So for you somewhat Draconian admins out there, you can control what your users can see, change & delete at a granular level.

There’s a lot going on with WSS v3 – both on the surface and under the hood.  So far our migration has met with positive results from our users – it’s cleaner, quicker, and just flat out prettier.  But now that you know why you want to migrate, in the next segment we’ll address how to plan such a migration and what gotchas and pitfalls to avoid. 

Moving to QuickBooks 2007

Anyone who has spent any time with me is familiar with my complete and utter loathing of everything Intuit.  But instead of ranting about how it’s an inferior, bloated, poorly-coded application that ignores both IT and accounting best practices, I’m going to provide some hopefully useful information on how to get QB 2007 to work in a network environment when you’re moving up from QB 2006. 

Like most of us in the SMB space, we have a lot of customers running QuickBooks.  We were eventually able to get virtually all of our SBS customers who purchased QB2006 running with the data living on their server.  Of course, this required installing the complete QB2006 app on the server – which I wasn’t exactly thrilled about.  As you may know, with QuickBooks 2007 Intuit has actually started making some progress towards a network friendly app.  Now, I don’t know if someone at Intuit started thinking – or if maybe Susan’s 2×4 finally hit home.  Regardless – with QuickBooks 2007 it now has a server install option (we no longer need to install the full app on the server), and it also supports running as a non-admin.  Who’da thunk?  [:)]

So, I’ve now moved three different clients from QuickBooks Pro 2006 to QuickBooks Pro 2007.  Since I didn’t like having the full QB app on the server, and I now no longer have to – I decided to completely uninstall QB2006 from the server, then run the server install of QB2007.  However, when I installed QB2007 on the clients, they couldn’t open the company files on the server.  After digging around for a little bit – I found the culprit:  Intuit.  Believe it or not, the QuickBooks 2006 uninstall routine did not remove the QuickBooksDB service.  Of course, QB2007 installs its own new data service (QuickBooksDB17) – so I was left with two QB data services running and not playing nice with each other.  Since I’ve seen this with every upgrade I’ve done so far, I figured there is a chance someone else might run in to it [:)]

The simple solution is to stop both services, remove the old QuickBooksDB service, then start the new QuickBooksDB17 service and you’re good to go.

If you need a refresher on removing Windows services – download the Windows 2003 Resource Kit Tools here.  Once you’ve installed the reskit tools on your server, click on Start | Programs | Windows Resource Kit Tools | Command Shell  then enter the following command:


Start the new QuickBooksDB17 service and voila!

Vista RC2, IE7 and SBS Self-Signed Certs

Yes Virginia – there is a Santa Claus . . .    oh wait, wrong story . . .

So as I mentioned in my previous post, I took the plunge and installed Vista RC2 on my primary production machine, and so far it’s going well . . .  granted a bit of a learning curve – but well worth it.

Like a lot of SBSers out there, we’re making extensive use of self-signed SSL certificates for accessing RWW, OWA, ActiveSync, etc.  Well, if you’re being a good little tech and running Vista as a non-admin, and you haven’t had much experience with IE7 yet, you might be trying to figure out just how to get those certs installed . . .

The first thing you notice when browsing to a site using a self-signed certificate, is that you don’t get to see the site right away – rather, IE7 gives you a full page warning insted of the old Security Warning pop-up.  So, you click to continue to the website, and you’ll notice that your address bar has changed to a deep red indicating the security risk with this site.  If you click on the ‘Certificate Error’ in the address bar, you can view the certificate.  But viewing the certificate – you notice one minor problem . . .   you don’t have an option to actually install the cert!

The thing is, you need to have administrator permissions to install your cert.  So here’s the trick . . .   click on Start | Programs.  Right-click on Internet Explorer and select ‘Run as Administrator.’  When prompted, enter admin credentials, and IE opens.  Navigate to your site, on the warning page select to continue to the site, then click on the Certificate Error in the address bar, and then view the certificate.  Now you have the option to install the cert.  But slow down there, young grasshopper . . .    if you just click through the add cert wizard like you do in XP, it’s not going to work for you.  You see, by default the add cert wizard is going to install the certificate for just the current user – and since we’re running IE as Administrator – you guessed it – the cert gets installed for the Administrator account – not yours.  So how do you get around this?  When you’re running the import cert wizard, you’re going to want to specify a location for the certificate:

Click Browse, the click to select ‘Show physical locations’ – then scroll up in the list, expand Trusted Root Certification Authorities and select Local Computer.

 Click OK, then finish the import certificate wizard.  Close IE (after all, you don’t want to be browsing as an admin)

Open IE, navigate to your site and voila!  There you go . . .

The Winds of Change . . .

Can you believe that this Wednesday, October 25th – marks the 5 year anniversary of the launch of Windows XP?  5 years!  Wow, no wonder things have been pretty comfortable and cozy on the help desk front – work with an OS for that long and you’re bound to know it inside and out.

But alas, progress marches on and we’re in for a whole new learning curve on the desktop (or more accurately, our users are in for a whole new learning curve, and we’re in for a completely revamped traning ciriculum)  

First, IE7 RTM’d last week – and there’s a bit of a learning curve there as well (honestly, how many of you cussed like a sailor the first time you tried to install a self-signed cert?)  I’ve been running the beta for several months now, and have become addicted – especially with the full-screen functionality when using web apps.  And I will admit that yes, IE is not only my primary browser, it’s the only browser I currently have installed.  Sure, I’ve read Vlad’s rants – but what can I say, I actually like IE  (yeah, I know – I’m sick & twisted). 

With IE7, Microsoft has been pushing out tons of add-ins, and free little applications, all using the Windows Live branding.  One of which being the Windows Live Writer, that I am actually using for the first time to compose this post.  So far, I have to admit that I’m impressed with this.  If you want to take a look, you can get it here – or read Vlad’s thoughts on it here  (after all, we all know that Vlad has a clear-cut opinion on EVERYTHING    )

And then we have Office 2007.  Of course, with what I do on a daily basis, Office for me is pretty much defined by Outlook, with Access and FrontPage (oops, SharePoint Designer) being a distant second & third . . .   I’ve also been running the Office beta for several months – and was totally sold until a few hiccups with the Beta 2 Technical Refresh (B2TR) – which resulted in Outlook crashing when I tried closing it, and getting a corrupt OST every time I opened Outlook . . .  this has been resolved – but more on that later.  So far the built-in RSS capability in Outlook, combined with the new kick-ass shared calendars view, the To-Do bar, and ease of adding Exchange accounts (users only have ONE choice to make – then it automatically detects the username, email address, and finds the Exchange server on the LAN – no more having to walk users through typing in the internal FQDN of their Exchange, blah, blah blah . . .  (at least, it worked that slick on a domain PC on the LAN)  Of course, there’s much more to Office 2007 – but those are the tidbits that affect me on a daily basis

Finally, our biggest change right around the corner is Vista.  Again, I’ve been running beta builds for quite some time – but admittedly on my home PC that I rarely ever use for anything besides the occasional web browsing.  Well, I was a few builds behind, and decided to take a serious plunge into the Vista experience – so I reinstalled my primary machine (Acer TravelMate C314XMi tablet) with the Vista RC2 bits yesterday . . .    I did download & run the Windows Vista Upgrade Advisor before starting the process – which was great for identifying what hardware and software I might have issues with.  So far, I have to admit that based on my previous experience with various Vista beta builds, I am very impressed.  The installation was painless – with all of the required information being entered up front, and the rest of the process being completely automated – reboots and all. 

After having lived through the migration experience from Win98 to 2000 Pro, and then from 2k to XP – I’m still scarred from application incompatibility, and driver issues (most notably a glaring lack of drivers) . . .   But, that doesn’t appear to be the case with Vista.  So far, I’m only having a couple hardware issues – most are pretty insignificant, but one – while not necessarily a show-stopper, is close.  My integrated Intel 2200BG wireless adapter is not cooperating.  Vista includes drivers for this wireless adapter, and it is installed, and when enabled it detects available wireless networks.  However – it refuses to connect to any secured network (WEP or WPA-PSK) – and while it will connect to an unsecured network – the connection only holds for ~5 minutes until it’s dropped and the adapter reports that there is no signal for that network any more.   Tad bit annoying . . .  especially since I only ever work wirelessly at home.  But on the flip side – my Verizon Wireless aircard works flawlessly.  As for the minor hardware issues – my function buttons to enable / disable things like WLAN & Bluetooth, or shortcuts to email, web, etc. are not working – neither is the On-Screen Display for these buttons, or my generic function keys (so I need to figure out how to disable NumLock when I’m in a remote assistance session  )  And finally, while my sound worked – Vista kept complaining that the audio drivers were not compatible with Vista – so I downloaded the Vista beta drivers for AC’97 audio from Realtek’s website – and I’m good to go.  (Of course, dealing with Realtek’s slow download site was a bit annoying in itself – almost 2hrs to download 26MB)

What really surprised me was that there were drivers for our printers here at the office.  Granted, they aren’t anything overly special or bleeding-edge – but again, I remember the issues obtaining print drivers in the past.  Adding our HP LaserJet 4200tn was a snap – I entered its IP, and Vista did the rest – queried the printer, determined the make/model and selected the appropriate driver and voila!  Now, it wasn’t quite that simple installing our Okidata C5150n color laser – Vista tried querying the printer – but wasn’t able to get the info it needed – so I had to select the driver the old-school way.   Now, the driver list didn’t include a driver for the Oki C5150n – but it was available via Windows Update – so all is well.

On the application front – so far just about everything is behaving itself.  Naturally, Office 2007 B2TR is playing very nicely with Vista – but the latest versions of other necessities like Adobe Reader, Java engine, Flash player, etc. all installed and ran without a hitch.  Notably, some of the little things that I use and depend on daily are working without issue.  The AutoTask for Outlook add-in installed and is running perfectly (which is a huge relief since that would have been a show-stopper for me if it didn’t) – and the AstTapi driver (that let’s me dial out from Outlook using our Trixbox phone system) is working nicely as well.

A few applications required a workaround to cooperate – most notably the Firewall Client for ISA 2004, and the connectcomputer wizard for SBS 2003.  You can get the details on getting these to work over at Sean’s blog – here and here . . .

The only application that is throwing me a bit of a fit is QuoteWerks – which is throwing an error when it tries to log in to its back-end SQL database – so I can’t really do anything . . .   but if I absolutely need to access a quote, QuoteWerks is installed on our Terminal Server – so I can get to it there. 

Finally, performance-wise – I have to say that this machine boots up and shuts down WAY faster than it did with XP Pro – and overall performance seems to be right on par, if not better than XP Pro. 

So, here’s to change ! 

A companyweb by any other name . . .

So, one question that I get asked regularly is if you can use a different name to access your companyweb.  For whatever reason, it appears SBSers have their own ideas of what URL / name they want for their individual intranets [;)]   The good news is that this is very simple to do . . .

1)   Pick a name you want to use –  for the purposes of this post, let's say we want to use http://intranet (yeah, real original, I know . . . )

2)   Add and entry to your DNS.  First and foremost, we have to make sure that intranet resolves correctly to your server's IP. 
     a)  So open your DNS snap-in, expand <servername> | Forward Lookup Zones | <domain name>. 
     b)  Right-click on <domain name> in the left hand pane, and select 'New Alias (CNAME)'.
     c)  Enter 'intranet' for the Alias name.
     d)  Enter the FQDN of your SBS in the target host field (e.g.  sbs.company.local)
     e)  Click OK  and close the DNS snap-in

3)  Edit the host-headers for your companyweb site.  Now we have to make sure that IIS knows how to route traffic properly.  You see, when IIS receives a normal http web request, it looks at the header of the request to get the URL that the user entered (in this case,  http://intranet).  IIS then looks at the websites to see if there is one that wants this traffic (has a host header present that matches the request URL).  If it can't find a site with a matching host header, then it sends the request to the default web site.  Since we want these requests to go to the companyweb site instead of the default web site, we need to add host headers to the companyweb site.
     a)  Open IIS Administrator snap-in
     b)  Expand <servername> | Web Sites
     c)  Right-click on companyweb and select Properties
     d)  On the web site tab, click the Advanced button
     e)  Click the 'Add' button on the top half of the page.
     f)  Change the IP address from (All Unassigned) to the internal IP of your SBS.
     g)  Set the TCP Port to 80
     h)  Set the host header value to intranet  (or whatever name you want to use)
     i)  Click OK
     j)  Repeat steps e thru i, only this time use the FQDN value in step h (e.g. intranet.company.local)
     k)  Click OK  |   Click OK  |  Close IIS Admin snap-in

4)  Re-extend Windows Sharepoint Services to the web site.  Just like IIS needs host headers to know where to route requests, Sharepoint central config keeps track of the sharepoint sites in its database.  Therefore, we need to re-extend WSS to the site in order to update the config database so it knows that we're using an alternate name to access the site.
     a)  Open Sharepoint Central Administration
     b)  Click 'Configure Virtual Server Settings'
     c)  Click 'companyweb'
     d)  Click 'Remove Windows Sharepoint Services from Virtual Server'
     e)  Verify 'Remove without deleting content databases' is selected, and click OK
          (when this finishes, you will return to the Sharepoint Central Administration main page)
     f)  Click 'Extend or upgrade virtual server'
     g)  Click 'companyweb'
     h)  Click 'Extend and map to another virtual server'
     i)  In the Server Mapping field, select  'companyweb'
     j)  Select to 'Use and existing application pool'
     k)  Select 'DefaultAppPool (NTAUTHORITY \ NETWORK SERVICE)' for the app pool to use.
     l)  Click OK
     m)  Close Sharepoint Central Administration.

Now, open IE and browse to http://intranet (or whatever name you used) and verify that it opens up your companyweb.  Note that after following these steps, you will still be able to access the site by browsing to http://companyweb.  This is because the native SBS functionality relies on the Sharepoint site answering to http://companyweb.  As a result, you can have your users use the new name you specified, but all of the SBS functionality (including the wizards in the SBS Admin Console and the companyweb links in RWW, etc.) will work just as before . . .  

Swinging Your Companyweb

So, with my last post I talked about using smigrate to backup and restore your SharePoint sites.  With this post I’m going to go one step further and attack a specific scenario that I seem to be getting more and more questions on – migrating your companyweb SharePoint site from on existing SBS 2003 installation to a new one.  This may be because you’re swinging your SBS to new hardware, or just starting over for whatever reason.

The idea is quite simple – you have a working companyweb on your current SBS, complete with tons of documents in various document libraries, a few custom lists, maybe a forms library, etc. – you’re moving to a new server and you want to move that site completely in tact . . .   it’s not an unreasonable request by any means – and luckily enough it is rather simple to accomplis – provided of course you know how to do it.  That’s where this post comes in  :^)

Obviously, the first step to making this happen is to backup your existing companyweb site using smigrate as I’ve outlined in my previous post.  The restore part is where everyone seems to be stumbling, so here’s what you need to know:

First, it is important to understand part of what the smigrate restore does.  When it connects to your SharePoint site to perform the restore, it is going to set the site template for the site based on the template that your backed up site was using.  Now, with SharePoint – setting the template for a site is a one-time thing – once you’ve set a template for the site you can’t reset it.  The only time a Sharepoint site is clean (e.g. does not have a template assigned to it) is right after Windows SharePoint Services has been extended to a website.  The first time you access your new WSS site, you have to choose your template before you can begin using the site. 

Most people who try to migrate their companyweb site using smigrate (or FrontPage) run in to this problem – their restore fails because the site is already in use.  Specifically, the smigrate restore process cannot set the site template for the new companyweb site because it already has a template set.  Sure, it’s the same template as the one you want to use – but the restore process still needs to set it to be sure.  As a result, the restore fails before it ever gets started. 

So – how do we get the restore to work?  Simple – we take the new companyweb site back to a clean state (where no template has been set).  To do so, we simply need to remove WSS from the companyweb virtual server, then re-extend it.  Now, before we remove WSS from the companyweb virtual server (on the new SBS server) – you need to be aware that this process is going to destroy this site (and all content).  Most of the time this should be an empty companyweb – but just in case you have some content in there, either extract it or back it up first :^).  So – your step-by-step process to get your new companyweb in a state that will allow an smigrate restore: (all steps are on the new SBS – assuming you have already completed the smigrate backup on the old server and moved those files to the new server).

1)   Open SharePoint Central Administration ( under Start | Administrative Tools )
2)   Click on ‘Configure Virtual Server Settings’
3)   Click on ‘companyweb’
4)   Click on ‘Remove Windows SharePoint Services from virtual server’
5)   Click to select ‘Remove & delete content databases’
6)   Click OK to acknowledge warning that you are deleting all content for the site
7)   Click OK
8)   When you return to the SharePoint Central Administration page, click ‘Extend or upgrade a virtual server’
9)   Click on ‘companyweb’
10)  Click on ‘Extend and create a content database’
11)  Select to ‘Use an existing application pool’
12)  Verify that the app pool selected is ‘DefaultAppPool (NT AUTHORITY / NETWORK SERVICE)
13)  Under the Site Owner section, enter the administrator email address for your domain
14)  Click OK to extend WSS to the companyweb virtual server.
15)  Once you see the page indicating the the virtual server was successfully extended, click OK to return the SharePoint Central Administration
16)  Navigate to http://companyweb, and verify that you get the Template Selection page.  Be sure and close this window – DO NOT click the OK button as this will apply a template to the site and you will have to repeat these steps before you will be able to restore your existing companyweb site.

At this point, your new companyweb site is in a clean state, and you can use smigrate to restore your existing companyweb backup to the companyweb on your new server.  Now, if you were using any 3rd party web parts on your old server, you want to be sure and install those on the new server before starting your restore.  And if this is a swing migration, your original AD will be in-tact, and the smigrate restore will also restore all permissions for the site as well.  Once the smigrate restore process has completed, there is nothing left to do – your companyweb will be back exactly how you left it – all permissions, settings, templates, etc. will all be there and you’ll be good to go  :^)

Older posts