Judy is a wise lady. (I assume, not a boy named Soo?)
In previous the versions SBS 4.x, the primary NIC MAC address was indeed the
keystone hook in the licensing. However, that didn't mean you couldn't run
on a new motherboard. What it meant was that if you ever attempted to
reinstall the SBS CALs (them floppies, you know?), you would find that they
would not install. This was not a licensing enforcement on the server, this
was to prevent pirating licenses to other servers.
I just this past week made a request to MS to clarify if there was a
different, same or no license trigger that was hardware based. The response
I got back was authoritative, but not entirely clear. The problem was I
didn't ask the question properly. I asked if SBS is using the same sort of
complex hardware tracking as XP and Office...something I didn't believe to
be true...and it isn't the case.
I believe that the license disks are still keyed to the MAC, at least until
I'm told different, that's what I will expect. However, this will not
prevent you from replacing the motherboard, nor will it prevent you from
reinstalling. What it will prevent you from doing is reinstalling from
scratch and running the license manager while having more than 5 users
connected. If the license manager is disabled, then you will not have users
knocked off, but you will not be honoring the MS license unless you seek to
resolve the issue through PSS. PSS will assist you with any technical
licensing issue if you are unable to reinstall your CALs.
Total answer is ....you should not sweat reinstalling your motherboard...at
least not regarding SBS licensing or operational issues due to licensing.
Okay, now to the real meat of this question. What happens when you replace a
motherboard on an SBS?
Short Answer? It works. Some issues can arise. I shall discuss this now.
Technically, when you replace the motherboard, if you put in an identical
motherboard, you will almost always find that the system boots back normally
in exactly the same configuration and operational status as before, assuming
that all hardware devices on the board were previously working on the old
Not sure what the point of replacing a fully functional motherboard with
another identical fully functional motherboard would be, but, hey, this is
my explanation so I'm going with it! :)
If you really dig into the settings, you will find that in fact the OS has
identified through PnP that you have an actually different NIC. It has a
different MAC, it's supposed to at least (uh-hem, Intel made that mistake
last year with same MAC on a whole production run!). You may see that the
Network Connections panel indicates Local Connection (2), or whatever the
default text is. However, as I recall, it actually assigns the previous
configuration to the new NIC if they have the same model type. [I'm sure
someone will clarify this point for me, but it doesn't matter to this
discussion, because.....] There will in fact be additional registry entries
for Network Adapters, even though they are identical.
So, if you are replacing the motherboard because the prior one already has a
dead NIC, you are actually less concerned about it seeing the new NIC as the
same as much as you are concerned about specifically "is anything going to
break, how complicated is it to fix?"
Let's backup a second and review globally what your concerns should be in
replacing a motherboard.
Before you do anything, you would need to take stock on why you are making
There are only THREE things about a motherboard swap that really can make
your 30 minute operation a nightmare instead
NIC not present or misdetected
Motherboard class change that alters the HAL required
Boot Drive controller change to a different model requiring different
If the NICs, motherboard and Boot controller are the same model, or at least
use the same drivers, you could pretty much do a shutdown, swap the board,
restart, and the only things on your checklist would be the following mostly
trivial and obvious points:
1. If the motherboards are same make and model, they might still not be
"identical". For instance, BIOS revisions might require updated drivers for
NICs, VGA, audio, whatever. You may find that you must install newer
drivers after the replacement to get normal operations.
2. As we all know, the CMOS settings on the motherboard may contain
things like (a) drive boot order, (b) ROM presence for SCSI, NICs, IDE or
other stuff that could conflict with things (c) Power Management settings
(d) chassis feature monitoring settings (e) etc, you get the point?
Before you pull the old motherboard, scan through the CMOS settings, and any
vendor specific "non-volatile" stored settings to ensure you match the new
board to that configuration.
3. Jumpers!!!! Ah yes, reset the jumpers on the new board to match things
like CPU speed, power transformers, fans, chassis
intrusion...whatever.....but you knew this, right?
4. Slot order of the cards. Again, you know what you are doing and you
are going to carefully reset every card back in the same slot. Honestly,
slot order is far less important than in the Win9x days, but it still can
matter so why change a sequence that was working.
5. Cable connections are probably the no brainer part of the exercise.
Now, we have the same model motherboard problem pretty well to the point of
power on. Remember, we probably are replacing the motherboard because
something was dead, that was the point of the exercise, so you will likely
be focused upon getting those settings for that hardware problem resolved.
If the problem was a previously dead NIC.....then we have a special case.
I'll get to that later. First, let's assume that it's the SCSI controller or
something else like that.
If the boot controller is what is changing, and you are adding a different
model for an intentional upgrade, you really want to start the process of
the upgrade BEFORE you tear down the original box. You really want to
preinstall the drivers for the new boot controller while you are still
running on the old one. For instance, if you are intending to add a new RAID
card, it's preferable to install the new drivers by booting on the old
system with the new card already installed. However, if the change is for a
boot controller on the new motherboard, we are not in Kansas anymore,
Dorothy, and you have a much more complicated problem. Please take a seat at
the read of the classroom and we need to talk much further....on a different
If the motherboard HAL is changing, this could be because you are migrating
an upgrade at the same time, perhaps going to dual processor. As often as
not, this can work, might not. There are tricks, but there are traps and
nothing but experience is going to help you here. Be careful about
volunteering a HAL change that you can't practice first on the sideline
without touching the production station. When it works, it's so stupidly
simple as to be a snore through reboot. When it fails you can be just
halted, or even totally blown away, reinstall.
Dead NIC. Good news. You probably can't break the system permanently if this
is the only thing that is different, but you can make the system seem like
it's totally hosed.
Let's focus on the NIC question now.
If you boot your system without a NIC installed, or with all NICs disabled,
or with a driver the OS rejects and refuses to activate the NIC, or anything
that looks and feels like there's no NIC, you will find a really shocking
thing happens in W2K that didn't happen in NT: W2K will automatically
disable many of the core network related services. On the next boot, these
services don't even TRY to start.....and you get enough red dots in the
event logs to fill your entire screen! The server will boot.....in about 15
minutes. AD will be totally wacky, but not damaged. WINS, DNS, RRAS,
FAX....everything practically will be off-track. The main problem will be
that Workstation Service and Server Service will have been disabled. If you
know which services normally start at boot automatically, you can repair the
NIC problem, recheck those services to make them start Automatically, and
How would you know what services to have running? Check the server before
you do the change, make a list. You could run "net start >service.txt" and
it will give you a file in the current folder for all services running at
that time. Now, run down that list to note all that are set for Automatic.
If you have this problem I'm describing, this little scratch pad will save
you a bunch of heartache.
As long as the NICs are correctly attached with drivers, you should be able
to match up the basic settings to the previous ones.
WINS, DNS, even DHCP are not going to be damaged by a NIC change. Neither
ISA, RRAS, or any other services care about the specific hardware devices.
As long as the IP matches on the new NIC to the old one, all those other
services will restart on the following reboot and work normally.
The only mind altering challenge is if you accidentally or intentionally
disable all NICs, or fail to get them working before a reboot.
FWIW, you can use the loopback adapter to troubleshoot NIC problems. If you
can't get a NIC replacement working, install the loopback (it always works!)
and then troubleshoot all the startups. Only the routing and web connections
won't work on loopback....for obvious reasons! You can even use a loopback,
to aide in replacing a NIC by attaching everything to the loopback while you
diagnose the NIC change process....but this could be another topic of
If you have a bumpy ride on the motherboard replacement regarding NICs, you
might chose to rerun the ICW to make sure everything is right. If it's a
smooth swap, I wouldn't bother.
I would always ensure that I'm working with the comfort of a full backup
before doing a major hardware change like a motherboard swap. Other
read more »