July 6, 2008
There’s no single more important thing to the long-term health of any network system than accurate time.
Without accurate time, there is no way to assure than any transactions flying in that environment will maintain fidelity. In other words…
There’s no way to know that databases, Active Directory, file systems, or anything else that uses any kind of timestamp isn’t shredding itself to bits.
10 years ago or so, time sync used to be much more of an issue. Oh sure, you could always load a dialer program that would call Colorado (in the US) and get a time adjust to the master clocks. But that was a major pain in the tookus. And it cost you money with each call.
Thanks to the glorious achievement that is the Internet, and a little gem called Network Time Protocol AKA NTP (including its eponymous sibling Simple Network Time Protocol AKA SNTP), time sychronization became largely a moot issue in data networks during the 90s.
The key to time synchronization, at least as far as maintaining a healthy network goes, is not so much having correct time (more on that in a minute), but having consistent time, which are two very different concepts.
Although it might make your users mad when the clocks on their PCs are off a bit, it is usually far more healthy for the average data network to be 5 minutes off everywhere, as opposed to having different parts of the network running on-time whle other parts do not.
The consistency of time in a data network has far-ranging implications. For Active Directory, one of the primary functions that depends on consistent time is network logon.
That’s because Active Directory uses Kerberos tickets to validate logon traffic. The tickets, which are by design time sensitive and expire so that captured traffic cannot be replayed and used to compromise systems in a classic man-in-the-middle attack, rely on consistent time. We’re normally talking about a 5 minute (which is an absolute eternity, in computer time actually) for everything to remain both hunky and dory.
The stampede rush to all things virtualization is poised to make time synchronization a key network design issue, all over again.
Because when the magic act that is virtualization makes the hardware go poof, there’s one major thing that goes away forever…
The BIOS Clock
Sure, a BIOS clock isn’t the end all, be all.
But it will keep you, and your systems, in the ballpark.
So if you aren’t spending time planning clock synchronization for your virtual systems, you’d best get that taken care of, and pronto.
|| posted by chris under biz, hardware, it pro, migration, rx, time, virtualization || comments (2) ||
||
June 26, 2008
The officially official version of Hyper-V just hit the download site today at noon Pacific time.
In an amazing feat of time-warping, this post was sent back in time to coincide with the exact moment of Hyper-V’s release.
Before you go all crazy downloading and installing Hyper-V, remember that upgrading your virtualization platform takes some planning and forethought…
If you care at all whether your virtual machines will still work, that is.
Some standard cautions about new versions of Hyper-V…
- Once you put Hyper-V RTM on, there’s no removing it.
- Virtual machines in a paused or saved state usually can’t be upgraded.
- Before you do anything else, export a copy of your virtual machines to an external drive exactly as you want them preserved.
- Archive all your exports into .zip files, so you don’t blow your only shot at an import later.
- Snapshots might not survive an upgrade. So merge your changes before shutting down your virtual machines for the upgrade. But push those exports first!
- Don’t forget to install the new Integration Services at some point, once you’ve verified your machines are all happy and working on the final release.
And for Pete’s sake…
- Keep a copy of the current version of Hyper-V that you are running, just in case. Otherwise, the export copies you pushed will be less than worthless.
In fact, why don’t you store that copy of Hyper-V used to make the export copies right WITH the export copies, so you’ll always have it if you need it.
In case the absolute very worst happens.
|| posted by chris under freebie, hardware, it pro, migration, rx, virtualization || comments (0) ||
||
June 20, 2008
With the public release candidate of Small Business Server 2008 floating around and about, there might be a few folks who want to stand it up inside of Hyper-V RC1.
When configuring a virtual machine to run SBS08, you’ll want to remove the native adapter that is configured by default, and add a Legacy Network adapter instead.
Otherwise, you’ll get the following error during installation
Network Adapter was not found
SBS08 can’t see native adapters until Integration Services are loaded. Which you really can’t do safely until after SBS is done installing.
Talk about a Catch-22, huh?
Also, certain things in SBS08 won’t install correctly without an adapter loaded. So you end up with a borked install.
Which maybe is something you’re after. But prolly not.
Go legacy adapter, if all you are wanting to do is put SBS08 through its paces with the least amount of hassle.
|| posted by chris under beta, hardware, rx, virtualization || comments (2) ||
||
June 19, 2008
OK…
So this is really just a tease shot, yes.
Instead, think of it as a whetting of your appetite.
|| posted by chris under beta, biz, it pro, virtualization || comments (0) ||
||
June 19, 2008
It’s officially unofficial…
My primary focus is shifting to Essential Business Server.
Well, not that SBS was ever really a focus for me. Still don’t know how that happened.
But it doesn’t take a badge to push information that matters, right?
First up…
Virtualizing Essential Business Server (posts tomorrow)
|| posted by chris under beta, biz, hardware, it pro, migration, mobility, rx, virtualization || comments (0) ||
||
