THE OFFICIAL BLOG OF THE SBS "DIVA"

Migration Step Thirteen: You installed in migration mode!

bradley — Sun, 08 Nov 2009 18:34:00 GMT

And we finished the install and the "migrate to Windows SBS" is ready to go.

Under the hood the FSMO roles have been added to this box and the SBS 2003 is no longer the king of the domain.

[Meanwhile I have to take a break to wash my car so I'll be back later tonight to continue blogging this test migration]

We have 21 days from this point to have the two SBS boxes work together. After 21 days you have to demote/remove the SBS 2003 box.

Migration Step Twelve: Turn off WSUS on the source server

bradley — Sun, 08 Nov 2009 17:10:00 GMT

Saying 'no to patches' reminded me that if you have an SBS 2003 R2 with WSUS on the box and ESPECIALLY if you have a Win2k8 server in the network, go into the source server box and disable the WSUS service there.

If you don't, during the install it may try to install patches on the server.

From the www.sbsmigrationtips.com site:

O. Disable WSUS on Source domain prior to migration

If you have a deadline set for a Windows 2008 update in WSUS that is past-due, your SBS 2008 setup can fail when the update is automatically installed and the SBS 2008 server is rebooted. Deadlines are not automatically set in SBS 2003 but can be set by the Admin through the native WSUS console. We recommend disabling WSUS for the duration of the migration.

Migration Step Eleven: Figuring out what you screwed up when the install gets stuck

bradley — Sun, 08 Nov 2009 16:35:00 GMT

Because I checked the box in the answer file to allow me to review each screen, I got stuck with an error that it could not find the source server and to check if the source server name was wrong.

Huh? I know that's the right name. I checked all of my reference materials including the David Overton SBS 2008 migration book that says:

I know that name is correct, what gives?

So then I do the Shift-F10 trick. I go to the SBS 2008 box that has a blue background and just that white box and the error screen there and there's no button to get under the operating system and to look at the log files... or is there?

Click to get your mouse on that server screen. Hit shift-f10 at the same time and you'll get a command prompt window pop up.

Now type in explorer and hit enter. What do you see?

A nice mouse clickable computer window that you can drill down into and find the setup log file.

C:\Program Files\Windows Small Business Server\Logs and then the setup.log file

The log file you are looking for is http://blogs.technet.com/sbs/archive/2008/10/01/key-small-business-server-2008-log-files.aspx the setup log file

And in there it says it can't ping the source server.

Huh?

And when I go back to the command window and ping the server name, indeed, I can ping by IP, I can ping by servername.domain.lan. I can't ping by servername only.

What the? My IP addresses are right, I can ping in other ways, is the firewall messing me up?

And this is where signing up for that SBS 2008 newsgroup will help https://connect.microsoft.com/sbs08/content/content.aspx?ContentID=8333 Because you need someone to bounce your "Dang, I'm stuck and I don't know what else to check" off of someone else's brain who has more brain cells than you do (especially during certain times of the install process).

Wayne Small had the necessary excess brain cells. He suggested that I check the subnet and then the netbios settings on the source server network card.

And bingo! In the changing of the network card down to one nic from two I stupidly didn't realize that I may have flipped nics and got it on the one that had netbios disabled. I reenabled netbios and it worked.

Once I reticked that box, the new server could ping the source server by name.

Last but not least, I do not check the option to have the newly built server get updates DURING the install. You are introducing change when you shouldn't be introducing patch change.

Say no.

Migration step Ten: Answer file

bradley — Sun, 08 Nov 2009 06:36:00 GMT

Create a migration answer file. Follow the steps on pages 19 through 23 in the Microsoft migration document.

Collect the information for the migration answer file.

Run the Answer File Tool. When you create a migration answer file, leave the Certificate authority name blank. For more information, see this blog post (http://sbs.seandaniel.com/2008/08/gotcha-using-sbs-2008-answer-file.html ).

I never choose to install updates during the install process. I can guarantee you that Microsoft does not test installs each time a new Patch Tuesday comes out. And so far there's been no need to insert an update into the install routine early on. You can patch AFTER the box is stood up.

Windows Live One Care is now defunct so I uncheck that. Forefront is a 120 day trial. So for me I'm not installing either one.

Then the part that is VERY VERY important

Leaving the cert name blank.

If you put in your domain name, you won't be able to choose your domain name when you run the domain wizard. Leaving it blank means that the server will do what it needs to do.

c Copy the answer file to removable media such as a USB memory card.

c On the destination server, change the BIOS settings so the server will not boot from the type of removable media used to store the migration answer file.

In my case I'll be saving this answer file to a virtual floppy disk.

In the HyperV settings, choose and setup up a virtual floppy disk.

Then in the settings of the machine, browse to this location.

Then unattach it so it can be attached to the new SBS 2008 we will be building

And now we're all set to start building the SBS 2008 box

So we start the boot process

And keep in mind that at this point you have to use tab and space bars in the HyperV if you are rdping into the box like I am

I don't put in a keycode at this point. First off this is a trial run, and I prefer to enter the code in later anyway. Just uncheck the "auto activate" box and tab over to the next and hit enter

Yes, I really don't want to put in a product key right now.

We only get a custom option

It starts to copy

It will then reboot

It will reboot again

And you'll start to see the normal blue screen boot up

Yes, I really do have a backup. Several of them.

Now Check the date/time and make sure they are correct to you and your time zone. The Time zone is VERY IMPORTANT as if they are majorly off the two systems can't domain join.

Then check your IP addresses, your gateway (where your router is)

On the next screen where it wants to confirm the business name details again... remember LEAVE THE CERTIFICATE AUTHORITY BLANK

The next screen will confirm your source server name .... and I'll showcase what I stupidly did wrong and what diagnostic things I did to help figure out what I did wrong in the next blog post.

Migration Step Nine: Check the health of Exchange

bradley — Sun, 08 Nov 2009 06:02:00 GMT

c Optimize Exchange Server and mailboxes. Follow the instructions on pages 16 through 17 in the Microsoft migration document.

c Empty the Deleted Items folder.

c Archive older mail

It can take a long time to migrate large Exchange Server mailboxes. It will take less time if you reduce the size of the mailboxes before the migration. To help reduce the size of the mailboxes, ask each of the users to do the following:

· Empty the Deleted Items folder

· Archive older mail

For additional information about optimizing Exchange Server, see the Exchange Best Practices Analyzer at the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkID=101795).

To empty the Deleted Items folder

1. In the Microsoft Office Outlook® messaging client, click Tools in the toolbar, and then click Empty "Deleted Items" Folder.

2. Click Yes on the warning dialog box.

To archive older mail

1. In Outlook, click File in the toolbar, and then click Archive.

2. In the Archive dialog box, click the down arrow in the Archive items older than text box.

Note

You must tell the users what date to select in the calendar that appears.

3. If you want to make sure that all the older mail is included, select the Include items with "do not AutoArchive" checked check box.

4. Click Archive all folders according to the AutoArchive settings at the top of the dialog box.

5. Click OK.

In Windows XP, the older mail is moved to the archive.pst file in C:\Documents and Settings\<user name>\Local Settings\Application Data\Microsoft\Outlook folder.

In the Windows Vista® operating system, the older mail is moved to the archive.pst file in C:\Users\<user name>\AppData\Local\Microsoft\Outlook folder.

Well since this is my test run, I will suck this up and not do this step, but in the real migration about a week before the real migration, I'm going to remind folks of the tasks they should have been doing all along...that is keeping their mailboxes clean.

Now Amy Babinchak and Philip Elder recommend to defrag the exchange databases:

The following can be done to test the health of the Exchange databases at the command prompt and with the stores dismounted (remember to backup):

MS KB192185: How to defragment with the Eseutil utility (Eseutil.exe)
TechNet: Eseutil /G Integrity Mode.
TechNet: Eseutil /P Repair Mode.
MS KB301460: Exchange Command-Line Parameters for Isinteg.exe Tool

So here's what I'm going to do:

In Exchange System Manager, right-click the information store that you want to defragment, and then click Dismount Store.

Now that the databases are stopped you can make a copy of these files (just in case)

In my case I have these on another drive, you may see these on your C: drive.

At the command prompt, change to the Exchsrvr\Bin folder, and then type the eseutil /d command, a database switch, and any options that you want to use.

This will take some time.

And then it will indicate it's done.

And don't forgot at the end to go remount the store

Migration Step Eight: Raising the functional level of AD

bradley — Sun, 08 Nov 2009 05:50:00 GMT

c Raise the functional level of the Active Directory domain and forest. Follow the instructions on pages 12 through 14 in the Microsoft migration document.

To be fair this probably should have been done sooner in the steps, but it's still in the prelim phase and before we've started the install of SBS 2008 so we're still during the time phase appropriate to this.

Download details: Windows SBS 2003 to 2008 Migration Guide:
http://www.microsoft.com/downloads/details.aspx?FamilyID=52b7ea63-78af-4a96-811e-284f5c1de13b&DisplayLang=en

On page 12-14 of that document is the instructions to change the functional level.

To raise the functional level of the domain

1. On the Source Server, click Start, point to Administrative Tools, and then click Active Directory Domains and Trust.

2. In the console pane, right-click the domain for which you want to raise the functional level, and then click Raise Domain Functional Level.

Note

The current domain functional level is displayed in Current domain functional level, in the Raise Domain Functional Level dialog box.

3. In Select an available domain functional level, click Windows Server 2003, click Raise, and then click OK in the warning dialog box.

Now we do the forest....

To raise the functional level of the forest

1. On the Source Server, click Start, point to Administrative Tools, and then click Active Directory Domains and Trust.

2. In the console pane, right-click Active Directory Domains and Trusts, and then click Raise Forest Functional Level.

Note

The current forest functional level is displayed in Current forest functional level, in the Raise Forest Functional Level dialog box.

3. In Select an available forest functional level, click Windows Server 2003, click Raise, and then click OK in the warning dialog box.

Just a reminder of all of the key migration resources

bradley — Sun, 08 Nov 2009 04:43:00 GMT

Just a reminder of all of the key migration resources that I'll be referring to and using during these blog posts/dry run of migation that I'm doing.

That first url -- www.sbsmigrationtips.com is actually a key SBS blog post entry that I got lazy enough to get a url redirect so I could find that blog post.

Then there is Philip's blog post -- MPECS Inc. Blog: SBS 2003 to SBS 2008 Migration Guide – v1.4.0:
http://blog.mpecsinc.ca/2009/06/sbs-2003-to-sbs-2008-migration-guide.html

Then the key official documents you need:

Download details: SBS 2008 Migration Checklist:
http://www.microsoft.com/downloads/details.aspx?familyid=F67148DA-CBA8-4222-8AE5-136A6597A340&displaylang=en

Download details: Windows SBS 2008 Migration Help:
http://www.microsoft.com/downloads/details.aspx?familyid=95E4863E-BB59-4A66-9FEE-9874E8903888&displaylang=en

Download details: Windows SBS 2003 to 2008 Migration Guide:
http://www.microsoft.com/downloads/details.aspx?FamilyID=52b7ea63-78af-4a96-811e-284f5c1de13b&DisplayLang=en

MPECS Inc. Blog: SBS 2003 to SBS 2008 Migration Guide – v1.4.0:
http://blog.mpecsinc.ca/2009/06/sbs-2003-to-sbs-2008-migration-guide.html

Migration Step Seven: Checking Exchange is ready to go

bradley — Sun, 08 Nov 2009 04:34:00 GMT

We're back on our Migration blog post series (hint all of the Migration blog posts are tagged with "Migration" for easy reference).

And now we're going to check and make sure our Exchange is ready to go:

I. In the source domain, check for the existence of an account named Postmaster.

SBS setup tries to create a Distribution List with the SAM account name of Postmaster. If it already exists, you will receive the following errors at the end of setup.

Setup errors due to an existing Postmaster account:

The e-mail distribution groups cannot be created.
Incoming and outgoing e-mail for Windows SharePoint Services are not configured.
Incoming and outgoing e-mail for Windows SharePoint Services are not configured.

To fix this, you will need to restore the source server, rename the Postmaster account and start the migration all over again. Alternatively you can complete the steps listed in http://technet.microsoft.com/en-us/library/cc626214(WS.10).aspx and http://technet.microsoft.com/en-us/library/cc626120(WS.10).aspx.

Now while I have postmaster@domain.com addresses underneath the Administrator account, these are not what this tip is talking about. They are looking for a specific Postmaster user account, not the Postmaster email account.

J. Check Exchange 2003 policies:

Existing Mailbox Management policies
Duplicate SMTP addresses in recipient policies
Invalid SMTP addresses in recipient policies

If any of these are present during the migration to SBS 2008, the setup will finish with the following errors:

Setup errors due to mailbox management policies or duplicate/invalid SMTP addresses in recipient policies:

The Exchange E-mail address policy cannot be configured.
Incoming and outgoing e-mail for Windows SharePoint Services are not configured.
Incoming and outgoing e-mail for Windows SharePoint Services are not configured.

How to check for Mailbox Management policies:

If you have Exchange 2003 or Exchange 2000 recipient policies that are ONLY Mailbox Manager policies and do not define e-mail addresses (they do not have an E-mail Addresses (Policy) tab), perform the following steps to delete the policies:

In Exchange System Manager, expand Recipients, and then select Recipient Policies.
To verify that a policy is only a Mailbox Manager policy, right-click the policy, and then select Properties. The Properties page must not have an E-Mail Addresses (Policy) tab.
To delete the policy, right-click the policy, and then select Delete. Click OK and then click Yes.

If you have Exchange 2003 or Exchange 2000 policies that are BOTH E-mail Addresses and Mailbox Manager policies (they have both the Mailbox Manager Settings (Policy) tab and the E-mail Addresses (Policy) tab), perform the following steps to remove the mailbox manager portion of the policy:

In Exchange System Manager, expand Recipients, and then select Recipient Policies.
Right-click the policy, and then select Change property pages.
Clear the Mailbox Manager Settings check box, and then click OK.

How to check for duplicate/invalid SMTP addresses in recipient policies:

In Exchange System Manager, expand Recipients, and then select Recipient Policies.
Right-click the policy, and then select E-Mail Addresses (Policy) tab.
Inspect the SMTP Addresses for any that are unchecked. If you find any, place a check in the box or remove that address.
Inspect the SMTP Addresses for any that have an IP address. For instance, @192.168.1.1. If you find any, remove those addresses that contain an IP address.
Click OK.

c Remove Mailbox Management policies. Exchange 2000 and Exchange 2003 used Mailbox Management policies for some types of e-mail. If these policies exist on the server running SBS 2003, setup will generate errors that will prevent you from completing the migration. Exchange BPA 2.8 checks for this condition. Remove Mailbox Management policies from the server running SBS 2003. For more information on how to do this, see the Keys to Success blog post.

Remove duplicate or incorrect SMTP addresses. Exchange 2000 and Exchange 2003 may have duplicate or incorrect SMTP addresses in recipient policies. If these addresses exist on the server running SBS 2003, setup will generate errors that will prevent you from completing the migration. The SBS 2003 BPA with the latest updates checks for this condition. Remove the duplicate or incorrect SMTP addresses from Exchange. For more information on how to do this, see the Keys to Success blog post.

I already ran the SBS bpa and didn't get any warnings, but I'm also going to run the Exchange BPA just to make sure:

Download details: Exchange Best Practices Analyzer:
http://www.microsoft.com/downloads/details.aspx?familyid=DBAB201F-4BEE-4943-AC22-E2DDBD258DF3&displaylang=en

And I'm going to run the "are you ready for Exchange 2007" test

And it reminds me that I've yet to flip the AD to the right levels... but it doesn't find any mailbox policies that I need to worry about.

Migration Step Six: Removing ISA

bradley — Sun, 08 Nov 2009 04:30:00 GMT

When I moved the SBS 2003 over to the (unsupported) HyperV platform, one of the things I had to do was to uninstall ISA 2004 and take the virtualized box back down to one nic.

Just a reminder of the steps I took -- this is from the SBS 2008 migration checklist:

c Uninstall ISA Server 2004. If ISA Server 2004 is installed on the server running SBS 2003, you must uninstall it before you can begin the migration.

c Uninstall the ISA Server 2004 desktop client. To uninstall the ISA Server 2004 desktop client, follow the instructions in this blog post (http://msmvps.com/blogs/kwsupport/archive/2008/09/07/uninstalling-isa-2004.aspx).

c Export your third-party SSL certificates. If you have any third-party SSL certificates installed on the server running ISA Server 2004, you should export the certificate for reinstallation on SBS 2003.

c Uninstall ISA Server 2004. Uninstall ISA Server 2004 from Control Panel using Add or Remove Programs.

Import your third-party SSL certificates. Once you have uninstalled ISA Server 2004 you will need to import your third-party SSL certificates onto the server running SBS 2003. To import your certificates, follow the instructions starting with the section “Installing the SSL Certificate into IIS” in this blog post (http://blogs.technet.com/sbs/archive/2007/08/21/how-to-install-a-public-3rd-party-ssl-certificate-on-iis-on-sbs-2003.aspx).

I also relied on Chad Gross's "killing off ISA" blog post here:

Killing off ISA - Aimless Ramblings from a Blithering Lunatic . . . - MSMVPS.COM:
http://msmvps.com/blogs/cgross/archive/2009/10/11/killing-off-isa.aspx

One setting I noticed that needed to be updated (especially if you removed the ISA a week or two before you did the rest of the migration was/is to remove the proxy ISA server settings from inside WSUS server proxy settings. If you leave that proxy server information behind inside of WSUS, your WSUS server won't sync up to get patch information.

Migration Step Five: Running the Source tool on the SBS 2003 server

bradley — Sat, 07 Nov 2009 07:19:00 GMT

http://msmvps.com/blogs/bradley/archive/2009/11/02/pre-migration-steps.aspx

So we're once again in our series of how to prepare for a migration.

To recap, we read, we watched.

We ran the www.sbsbpa.com on the server

We ran the IT Environmental Health scanner - http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=dd7a00df-1a5b-4fb6-a8a6-657a7968bd11 to ensure all was well.

We checked the primary account.

We took a backup.

We took a system state backup.

{heck we even used the Disk2vhd to move it to a test bed just so we can run this test before doing this for real}

We're now ready for the Migration prep tool:

H. On the Source Server, run the SBS 2008 migration prep tool.

This tool performs the following actions:

Installs update 943494 on the SBS 2003 server to extend the migration grace period from 7 to 21 days.
Runs ADPREP to update the forest, domain, and group policy object access control entries.
Changes Exchange 2003 from Mixed mode to Native mode.
Adds the Authenticated Users group to the Pre-Windows 2000 security group.

If Exchange 2003 is not running in Native mode, Exchange Server 2007 will not be installed and you will have to start all over. The error message is Exchange Server 2007 cannot be installed. For more information, see this.

If the Authenticated Users group is not a member of the Pre-Windows 2000 security group, then standard users will not be able to access the Remote Web Workplace. The error message they will see is: Cannot connect to the Remote Web Workplace site. To continue, contact your network administrator.

The tool can be found on the SBS 2008 media under the tools folder. If you don't have a DVD on the SBS 2003 (like I don't) stick the DVD in any other computer, copy the tools folder onto removable media and put it on the SBS 2003.

Now that we have umpteen backups, on the SBS 2003 box launch that Sourcetool.exe file

We have a backup so we're going to check the box.

The installer starts

When it finishes it's now prepared the SBS 2003 for the migration.

What it did in the background is install

Application KB943494 (Hotfix for Windows Server 2003 (KB943494)) was installed.
Does the ADprep and flips Exchange to native mode
Adds the Authenticated Users group to the Pre-Windows 2000 security group

MESSAGE Security Enabled Local Group Changed:
Target Account Name: Pre-Windows 2000 Compatible Access
Target Domain: Builtin
Target Account ID: BUILTIN\Pre-Windows 2000 Compatible Access

Reboot and we're ready for the next step.

Next step building the answer file.

Holy cow this really works but this is really unsupported

bradley — Fri, 06 Nov 2009 20:15:00 GMT

Holy cow this really works! - THE OFFICIAL BLOG OF THE SBS "DIVA":
http://msmvps.com/blogs/bradley/archive/2009/11/05/holy-cow-this-really-works.aspx

Please keep in mind that in the next few days as I blog about the migration from SBS 2003 to SBS 2008 test run that I'm doing that the SBS 2003 installed in HyperV is totally and utterly unsupported when it's in that HyperV like that. Exchange 2003 is not supported in HyperV, only in Virtual Server.

If you put SBS 2003 on a platform that virtualization is not supported, you will get push back from support where they will tell you you have to recreate the issue on a supported platform.

Support policy for Microsoft software running in non-Microsoft hardware virtualization software:
http://support.microsoft.com/default.aspx/kb/897615

Exchange is normally the one that sets the support line in the sand.

Summary Support Statement*
This configuration is Not Supported.

* Customers with Premier-level support agreements should contact their account manager for more information
* Additional information is available in the "Support policy for Microsoft software running in non-Microsoft hardware virtualization software" which can be viewed here

Support Statement Details

Product: Exchange Server 2003 Service Pack 2 on Hyper-V with Windows Server 2003 SP2 (x86) Guest OS

More Information

For Exchange Server 2003 Service Pack 2 only Virtual Server 2005 R2 and later is supported as hardware virtualization software. See here for specific configuration information.

http://www.windowsservercatalog.com/svvp.aspx?svvppage=svvpwizard.htm

For those asking about ESXi

Summary Support Statement*
This configuration is Supported.

Support Statement Details

Product: Exchange Server 2007 Service Pack 1 on VMware ESXi with Windows Server 2008 (x64) Guest OS

Search the Knowledge Base for information related to this configuration

More Information

Exchange 2007 SP1 and later must be deployed on the Windows Server 2008 operating system. (Note: Windows Server 2008 R2 is not currently supported with Exchange Server 2007 on hardware virtualization). For more information about support and scaling see the Microsoft Support Policies and Recommendations for Exchange Servers in Hardware Virtualization Environments here .

Supported features: Anti-Virus, Back-up Software, Virtual Machine Management Software, Cluster Continuous Replication (CCR), Virtual Processors

Unsupported features: Unified Messaging, Dynamically Expanding Virtual Disks, Virtual disks that use differencing or delta mechanisms, Hyper-V Quick Migration combined with Exchange Clustering, Virtual Machine Snap Shots

Making sure you don't sync with the Parent

bradley — Fri, 06 Nov 2009 05:41:00 GMT

I have eventsentry.com on my existing SBS 2003 which also means it's now on my HyperV clone. So I kept getting a time change alert..

DATE / TIME 11/5/2009 9:36:21 PM MESSAGE The system time was changed.
Process ID: 1368
Process Name: C:\WINDOWS\system32\vmicsvc.exe

I had forgotten to uncheck the box on the time sync setting on the HyperV. You still want the DC inside the HyperV to get and grab it's own time from the various ntp time sync portals and not try to sync up with the HyperV parent.

Uncheck the box in that settings window and all is well.

Holy cow this really works!

bradley — Fri, 06 Nov 2009 02:10:00 GMT

And I'm not talking about the cleaning products either!

http://www.holycowproducts.com/

I'm talking about the Disk2VHD tool here:

http://technet.microsoft.com/en-us/sysinternals/ee656415.aspx

So merely using that... we first make VHDs of our existing physical box. Mind you the first time I tried to cheat and only backup the C and the E as the F is data, but because the E and F are on a single volume, the system would not fully load those two drives. So make sure if you have multiple drives on a single volume that you backup the drives on that volume as a whole.

I backed it up on an external usb harddrive. It took from about 10 p.m to 3 a.m to back up my entire server. I then moved the usb harddrive over to the new HyperV server and copied the VHD files over to the new server. I set up the settings for the new SBS 2003 on the server with 4 gigs of ram, 4 processors, and two harddrives, matching the vhd's and browsing to their location on the box. I then turned on the HyperV server, sat back and waited for the blue screen......

THAT NEVER OCCURRED. Yes, you read that right. I took a physical SBS 2003 that was installed with HP management software on a five year old ML370 G4 and plopped it up into a HyperV sitting on a brand new ML370 G6 and there was no blue screen freak out.

Once it booted up in indicated it would need a new activation in three days and that the hardware had change significantly (no kidding dude, that hardware has definitely changed)

Keep in mind should I need to activate this box, I will not impact the running box (as in it will not suck over the activation from the running box). And normally they are more lenient on servers than they are on workstations and most of the time they will activate again just fine. The only gotcha you need to watch is two things:

1. OEM installs should not be doing this from a licensing standpoint. You are not legal to move that license from an OEM to a HyperV. The license is bound to that hardware.

2. Some (not all but some) OEM builds may be BIOS locked. Certainly the new Foundation Server in the 2008 era has a bios check to ensure it's on HP true hardware and will not install in a virtual setting. I've even seen some SBS 2008 reseller kits that have this bios check as well.

So OEMs should not be using this methodology at all.

[Before the licensing police come and say I shouldn't activate this as I still have my running SBS 2003, keep in mind I have SA so I have cold server rights. Granted the server isn't cold but the only reason I'm doing this is to give me a means to fully and completely and utterly to test my SBS 2003 to SBS 2008 migration in a sandbox before I do it on the real network. So if anyone wants to arrest me for MS licensing non compliance, you have three weeks to lock me up. Ping me via the contact box for directions to my office.]

Because the OS is 2003 and not the nice 2008s or Vista/Win7 era that has the hyperV integration bits preinstalled, to get a mouse working remotely you have to go up in the tools and install the HyperV extensions and hit the tab key a lot to get it installed and then reboot it. Once it comes back up you now need to clean out the old physical nics.

If you try to go in there and reset up the nic with the original IP address you get a warning from the box that network cards are still there:

But if you go into device manager they won't be there.

Step 1: Open up a command prompt

Step 2: Type – “SET DEVMGR_SHOW_NONPRESENT_DEVICES=1″ and hit

Step 3: Type – “START DEVMGMT.MSC” and hit

The go back in and put in the static nic entries and rerun the CEICW (in SBS 2003) and the Fix my network wizard in SBS 2008.

In my case as well, since I have this HyperV box hanging off a totally separate IP address right now, it was not authorized by Exchange Defender to email out, so until I enter in a trouble ticket to add this server temporarily as an authorized outbound emailer through the Exchange defender network, I just bounced it off the smtpauth.sbcglobal.com for the time being to fully test the functions of the box. So it's actually kinda funny now as I am getting monitoring emails from the two servers now and I actually had to go back in and edit the from address so I'd know which one was coming from the HyperV box and which one was from the regular still running box.

But the beauty of this is, is that I can now do a full trial run of the SBS 2003 to SBS 2008 migration in a sandbox that won't impact my real machine. Furthermore, should I decide to do so, when it comes time to do the real migration I can theoretically redo this PtoV that I've done here and start the migration from the virtual SBS2003, this time of course turning off/blocking the old existing machine from putting in email during this migration timeframe. This then leaves the old existing SBS 2003 totally intact and non impacted by the migration process.

MPAN and action pack

bradley — Thu, 05 Nov 2009 07:38:00 GMT

http://msmvps.com/blogs/bradley/archive/2009/10/30/so-what-about-those-action-pack-licenses.aspx

It's been several days and I still don't have any word one way or the other about the status of those folks in the MPAN program that no longer "fit" into the new Microsoft Partner Network.

And I'm not feeling good about the fact that the gentleman from the MPN phone number 800-765-7768 hasn't called me back when he said he would the following day. The problem with dealing with a large blob of a corporation is that it's hard to find the right person to talk to and when you call into 800 numbers you may not be in the right spot to get an authoritative answer.

First off to anyone who signed up for MPAN or who urged their clients to sign up for MPAN, especially if it was due to something I posted, I'm sorry. I'm not feeling good if you did so on my recommendation and now this occurred. If I were even a moderately rich person, any CPA who was in this limbo state of not possibly now being licensed properly, I'd offer to buy them licenses. But I can't afford that. All I can do is say I'm sorry and be more wary about marketing based offers next time.

I still hope that someone in a position of power will understand the situation here and waive the licensing for these impacted folks and just let them continue to use the existing Action pack licenses and grandfather their use rights. I only hope that someone at Microsoft understand that it's not good business to design a marketing plan for a product that entices folks into a software licensing offer that was designed to get CPAs to be interested in an accounting product, that if they can now no longer qualify for, means that it's a big chunk of change that suddenly comes due that no one was anticipating. Especially now in this economy.

My firm is not in this category of being affected, because I kept on recommending that we buy the Software assurance via the 3 year licensing. So maybe that makes me a bit of an ingenuous person since if I kept recommending 'normal licensing' to my firm, in the back of my mind, I guess I always had a doubt that Office Accounting would never stand a chance and that some day Microsoft would pull back on the MPAN program and folks would be left high and dry.

Some of these CPA firms do have an IT side of them, do have folks that are SBSCs, do qualify to be in a competency in the Microsoft Partner Network. Those firms are not at risk because the qualify as a "traditional" Microsoft Partner. Either in general IT, or in Microsoft Dynamics, they will fit. But if they fit, it's probably because they always fit as they had an IT niche.

But it's the folks that are only in the program because Office Accounting thought they'd go after Quickbooks that concern me. It's these folks, a small group of people that I just can't see fitting anymore into the Microsoft Partner Network. Their primary focus was and still is Quickbooks and not the Dynamics stack. I can't see where they fit into the Microsoft Partner Network. Microsoft can say 'well we separated out the Action pack, Microsoft Partner network and the MPAN program about a year ago'.

That's all fine and good, but Microsoft, you don't treat your customers like this. It's not their fault you took on the 80 pound Gorilla of Intuit and you lost. It's not their fault the economy kicked in and someone decided to retrench. It's not their fault they are not caught in the downsizing, layoffs and product cutting that Microsoft is into now.

But it is Microsoft's fault that even with the layoffs you are still so big that I can't find the answer, and we're still in limbo.

I'm still hoping that someone in a position of power will do the right thing and grandfather folks that were in the MPAN program and allow their licenses to be in perpetuity just this one time. I honestly don't think it's too much to ask for given the circumstances of the reason for the closing of the MPAN program. I'm hoping that like in most instances of dealing with Microsoft, that silence I'm getting means that someone somewhere is taking action.

I hope.

P to Ving with the Sysinternals tool

bradley — Thu, 05 Nov 2009 05:13:00 GMT

http://technet.microsoft.com/en-us/sysinternals/ee656415.aspx

Testing this out. Have a HP ML370G4 that has a physical install of SBS 2003 on a raid/hardware system. Have a HyperV on an HP ML370G6. In a test run (where I screwed up because I didn't understand that I needed to ensure I copied the VOLUME which included both an Exchange data drive and a data data drive) I booted up the resulting VHDs and they didn't BSOD with the move.

Mind you they had ghosted nics so that's to be totally expected, and easily removed from the machine and then a rerun of the CEICW and that box was basically a running system.

How to remove ghost nics on vmware machines that have been P2Ved « Ramblings of a semi sane person:
http://secadmin.wordpress.com/2009/02/11/how-to-remove-ghost-nics-on-vmware-machines-that-have-been-p2ved/

Step 1: Open up a command prompt

Step 2: Type – “SET DEVMGR_SHOW_NONPRESENT_DEVICES=1″ and hit

Step 3: Type – “START DEVMGMT.MSC” and hit

Step 4: Once the Device Manger opens to the “View” menu and select “Show Hidden Devices”. Expand the Network Interface portion of the device tree and you should be able to remove the phantom NIC.

I'm doing it again as I need the second volume copied, and it will want reactivation in three days because I just ripped it off the hardware it was tied to, but it appears to do a physical to virtual without causing a bsod. I'll do a longer blog post explaining the process tomorrow.

The other thing you can use this for (assuming the proper XP movable licenses) is that you can PtoV and make a real XP that XP Mode underneath that Windows 7. Kinda kewl huh?

So you have an app you want on Win7 and you don't want it to throw off a UAC warning?

bradley — Wed, 04 Nov 2009 02:59:00 GMT

So you have an app you want on Win7 and you don't want it to throw off a UAC warning?

LUAbuglight it!

Find the offensive permission sticking part of the program and adjust the registry permissions or file permissions. Very very very cool tool. I'll blog it in action later.

http://blogs.msdn.com/aaron_margosis/pages/LuaBuglight.aspx

LUA Buglight 2.1 is here. LUA Buglight identifies admin-permissions issues ("LUA bugs") in desktop applications. I've made a lot of changes to LUA Buglight since the last "2.0 Preview" that I posted, so the version number has been bumped up:

Support for Windows 7, Vista and XP, and corresponding Servers (2008 R2, 2008, 2003)
Support for x64 (except on XP/2003)
Completely revamped Reporter -- streamlined and with more detailed results

Note: The new Reporter has necessitated a new file format, so the new Buglight cannot read reports generated from older versions of Buglight.

One thing that is seriously missing is documentation -- I hope to have that posted here in some form soon. The basics:

On XP/2003, you need to run it as a standard user, and you need the username/password for an administrative account; on Vista and higher, you need to run it non-elevated as a member of the Administrators group, with UAC and admin-approval mode enabled.
Tell it what program to run, then run it. Whenever your app performs an action that fails unelevated, it will repeat the operation with admin rights before returning control back to the program. If it fails without admin rights and succeeds with admin rights, details about that operation get logged.
Click the "Stop Logging" button to close the log file; by default this will also open the Reporter and show the results.

Another feature that isn't present yet is that while LUA Buglight does an excellent job of identifying when a program performs operations that succeed only when run as administrator, right now it doesn't provide the details to fix it if you can't modify the source code. My plan is to turn that into a community effort by documenting the report's XML format and then providing some PowerShell scripts that process the results and point to app-compat shims, permissions changes, or other mitigations for the identified problems.

I wish I could work on LUA Buglight full time, but it's an unfunded, spare-time effort, outside of my day job. I know that LUA Buglight would be a lot more useful with documentation, but it's more useful posted without documentation than it is not posted at all waiting for me to write up documentation.

More information will be posted to this blog.

Migration Step Four: The most important backup of all

bradley — Wed, 04 Nov 2009 02:50:00 GMT

So before you run the source tool on your SBS 2003 box in addition to the normal backup. In addition to the possibly paranoid backup you need to do with a third party program like Storagecraft, Acronis, DriveImageXML (paid not free), make sure you do ONE MORE BACKUP.

One that I'd argue is the MOST important one of all.

Just and nothing else but, the system state backup.

With that you can roll the AD back should something occur. Don't stick it on your normal backup location as well, ensure that you park it several places, on the local drive, possibly on a usb drive but ensure you have a system state backup as it's key here before you being the migration.

The video card RDP bug nailed me today

bradley — Tue, 03 Nov 2009 20:23:00 GMT

So I'd always heard about this, not seen this in action... well now I did today. Nvidia video driver and AFTER the installation of .NET family patch (that I had been holding off installing) I could no longer remote to a machine. I would rdp and the windows would immediately come back.

When remotely connecting to the event viewer I saw this:

Mind you, nothing was actually being seen on the workstation in question, I just couldn't connect to it after the install of the .NET family update. (951847 - http://msmvps.com/blogs/bradley/archive/2009/11/02/net-patch-gets-offered-up-all-by-itself.aspx)

Brad Rutkowski's Blog : \SystemRoot\System32\RDPDD.dll failed to load:
http://blogs.technet.com/brad_rutkowski/archive/2008/01/04/systemroot-system32-rdpdd-dll-failed-to-load.aspx

Getting a new driver didn't help, I had the latest driver.

Only the registry fix worked:

It's a registry fix that increases the size of the session image space. Add the following key:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]

"SessionImageSize"=dword:00000020

Where 00000020 is hex for 32

Migration Step Three: Pre-migration steps

bradley — Tue, 03 Nov 2009 06:26:00 GMT

http://blogs.technet.com/sbs/archive/2009/02/19/sbs-2008-migrations-from-sbs-2003-keys-to-success.aspx

So while I'm in the process of still getting the workstations ready to go for the change out of ISA (removing ISA client on the workstations, ensure that the proxy settings are removed, etc. etc. so let's recap where we are at in our planning stage of the pre-steps of migration.

A. Read through the migration guide before starting.

We've read. Killed a few trees in the process too.

B. Watch the migration video demos and online training.

We've killed a few electrons in the process.

C. Join a SBS 2008 Newsgroup.

Okay I personally kinda have that one covered, but the best 2008 one for migration issues can be signed up to via this link.

D. Practice a migration in a test environment.

Right now I'm testing the plain running of a server on the new HyperV environment. While I have done dry runs/practice runs of clean SBS 2003 boxes, I'm still shooting to use SCVMM to pull a PtoV version of my actual SBS 2003 so that I know EXACTLY what I'm facing.

E. On the source server run the SBSBPA.

We already covered how to install www.sbsbpa.com on the server and to ensure all was clean

F. On the Source Server make sure the Active Directory is healthy.

While we've done dcdiag and what not, we have not showcased how the IT Health Scanner helps in this process.

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=dd7a00df-1a5b-4fb6-a8a6-657a7968bd11

So we install it and run it on our SBS 2003 boxes

First you enter the internal IP address of the firewall (on a SBS 2003 box that's most likely to be the IP address of the server if you have a traditional two nic setup and haven't yet removed ISA fully)

Click scan to start scanning the network.

Let's see what it came up with....

The upper AD section looks clean ...that's good...

It's saying that the domain controller is listening on multiple addresses (well right now it still has two nics so that's kinda to be expected)

It also says I have an orphaned network interface mainly because I'm doing this remotely and it's reacting to that remote session.

One of the unusual errors is pointing to KB 884776 http://support.microsoft.com/default.aspx?scid=kb;en-us;884776 and saying that I have the domain controller configured to allow time connections greater than 172800 seconds. I honestly haven't seen issues leaving that one as is for purposes of migration.

Now we're up to item G:

G. On the Source server, check the Primary group of the account you will use to install the SBS 2008 server into the domain.

Make sure the Primary group is set to something besides Domain Admins, Enterprise Admins, or Schema Admins. Otherwise, you may receive the following pop-up error during the migration:

The user account does not have the permission that it needs to join the domain. The user account must be a member of the Domain Admins, Enterprise Admins and Schema Admins groups.

In the properties of the user account, click the Member Of tab, and at the bottom look for the Primary group.
Make sure the Primary group IS NOT : Domain Admins or Enterprise Admins or Schema Admins.
To change it, select Domain Users and click the Set Primary Group button.

What some folks do is set up a special migration administrator account for purposes of the migration.

On the member of tab, make sure that the primary membership is domain users.

H. On the Source Server run the SBS 2008 Migration Preparation tool.This tool performs the following actions:

Installs update 943494 on the SBS 2003 server to extend the migration grace period from 7 to 21 days.
Runs ADPREP to update the forest, domain, and group policy object access control entries.
Changes Exchange 2003 from Mixed mode to Native mode.
Adds the Authenticated Users group to the Pre-Windows 2000 security group.

Since I don't have a functioning DVD on my source server, we can move it over to that box via usb or other means. Just zip up the contents of the tools folder and move it over to your source server box.

So I moved it over to the old server, start the running of the tool and what should smack me upside the head?

The RUN A BACKUP GIRLFRIEND screen.

The system state run a backup screen.

The run an extra backup just because you feel like it screen.

The run an extra backup so you don't hate yourself screen.

The no, really you really want a couple of backups to give you options screen.

Our lesson is over tonight because I'm going to make sure I have SEVERAL means of backup right at this point. The more ways we have backups, the more options we have should something arise.

Class dismissed for the evening, see you next session. Don't forget your homework assignment to ensure you are signed up for that SBS 2008 newsgroup.

Net patch gets offered up all by itself

bradley — Tue, 03 Nov 2009 06:09:00 GMT

One of the recent changes to the net family patches is now 951847 is offered up all by itself on Microsoft Update.

If you are deploying patches in other ways, it's a wise idea to take from Microsoft update.

Just do that one all by itself.