Hello world!

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!

Advertisements

Adding a Windows 7 client to Server 2008 R2, known FAIL

Hey there,

Just came across something really annoying.  While trying to do something else, I stumbled over a known bug in Server 2008 R2 that causes Windows 7 clients to be unable to be added to the domain.

Here’s the deal.  If your domain name, plus the client’s machine name, add up to more than 15 characters, then the client will fail to be added to the domain.  The domain controller seems to reject the client computer for no apparent reason.

But if you shorten the client computer name so that that, plus the domain name, are less than 16– suddenly the machine is added to the domain with no issues.

There is a hotfix for this (at this point, maybe it’ll be rolled into a service pack someday), but you have to ask for it. (be sure it is for the correct architecture– I’m on a 64 bit server, but it thought I needed an x86 hotfix…)

The blog post that gave me the headsup: http://news.softpedia.com/news/Windows-7-Beta-Can-039-t-Join-Domains-with-Names-Exceeding-15-Characters-102423.shtml.

Frustrating.

Dude, what’s my PID?

Howdy all and happy holidays!

I’m currently prepping for the long haul of writing a 1100+ page book over the next six months.  I’ve got a big Dell server on order, am building VMs like crazy, setting up my portable apps, and figuring out which machine will run what.

To that end, I had a bunch of VMs that I built over the last year to do SharePoint Saturday presentations.  I had built them over the course of several months, for this reason and that.  Today, after resetting one of the VMs to it’s last snapshot, it prompted me to reset it’s activation.

Now, I have several technet subscriptions (as well as Action Pack and MSDN).  Each one is intended to be used for a different project or reason.  Therefore, all of my VMs for presentation and book writing should be all using a certain technet subscription’s PIDs.

Just to check before I activated the VM again, I wanted to see what PID was used for that machine.  I downloaded Belarc Advisor, a tool I’ve used for a decade to keep track of my PIDs and software.  Great little program.

Didn’t work on server 2008 R2.  It seems, as time has passed, Windows has started, reasonably, to encrypt it’s keys, making Belarc useless as an OS PID resource.  Same thing with Magical Jelly Bean, another great PID finder resource.

So.  How does one go about figuring out what activation key they used with a particular server?

I’m not sure.  What I did was use slmgr at the command line.  If you use:

slmgr /dlv

It will bring up a report of your activation status with the last five digits of the key displayed.  That at least let me check the product keys available on my accounts and discover that I’d originally activated this VM with the wrong key (according to how I want to manage activating my VMs).

Sigh.

Now I don’t find the slmgr option to be optimal, but for now I haven’t found a better, free, option for finding out which machine is using what PID, never mind having a convenient report to archive.

But hey, at least no one is going to be able to sneak into your registry and copy your PID any more.  I am sure you will now sleep better knowing your PID is safe….

Windows Server 2008 R2 Firestarter Event- Finally!

Howdy all!

It’s been a little while since I posted, but I have not been sitting on my laurels during that time.  No siree.

I have a post that’s still in draft (I need to redo the pictures, they’re too blurry) about how to create a boot from VHD, dual boot situation on a Macbook Pro (13" to be exact) so you can have Windows 7 and Server 2008 R2 available, natively.

There is a quirk I’ve experienced with the EFI partition that makes creating the VHD for boot a little different than that for a BIOS situation.  Otherwise, boot to VHD works splendidly.

And, as if to prove it, I will be running, single-handedly, a four hour, demo filled, Server 2008 R2 Firestarter launch event in Pittsburgh PA, December 16th, from 10am- 4pm– all using Hyper-V while booted to my Server 2008 R2 VHD.  That’s right, running VMs using a VHD image itself as the host.

The event will be covering about 12 (or more, depending on time) live, real time demonstrations of new capabilities of Server 2008 R2, like remote management of Server Core, Branch Caching, Remote Desktop Services, Administrative Center, AD Recycle Bin, and of course, Hyper-V and Boot to VHD.  Over the course of about 4 hours, I will be using up to 12 different VMs to run through each demo– the Branch Cache and RDS demos in particular are pretty VM heavy.

For those of you who have been following this blog from the beginning, you know that the whole reason why I started trying to get Windows 7 and Server 2008 R2 to work on a Mac laptop was to be able to host a Firestarter event.

And now, this Wednesday, that wish will become a reality.

There are still seats available, if you’d like to register by clicking here.  Registration closes at about 10pm (EDT) on the 15th.

I’ll let everyone know how it goes, and maybe give you tips and tricks for your own event (or at least let you know what happened so nothing like that can happen to you, lol).

Thanks everybody and Happy Holidays!

Installing Server 2008 R2 (RC) on a Macbook Pro

 

My apologies for the delay.  As you know, I was inspired to try to install Windows 7 and Server 2008 R2 natively on a Macbook Pro 15" (the non-unibody kind) in order to, eventually, do some server 2008 R2 firestarter events on the box (which requires hyper-v).

 

In the previous entries on this blog, I chronicled installing Windows 7 and experimenting with XP mode.

 

In this belated entry I am going to chronicle installing Server 2008 R2.  There were some significant differences in the experience.  Specifically, I had installed Windows 7 32 bit without giving it much thought in my first experiment.  And it did work wonderfully.

 

However, Server 2008 R2 comes only in 64 bit, and the installation of 64 bit Windows is a little different on a Mac.

 

(To start, if you have a Mac OS already installed on the laptop, you will need to hold down the "c" key during the boot process to tell the Mac to boot to DVD, otherwise it’ll just keep booting into the existing OS, making you crazy.)

 

 In my adventures, I had a copy of Server 2008 R2 on a DVD given to me at TechEd.  So I tossed it into the Mac, held down the "c" key, and waited for the install to begin…

 

…and saw this:

 

 

?!  What the heck does that mean?  Is it a bad disk?  After trying it out on a few different machines, I discovered this; the disk was fine, other machines could boot to it and see it’s files fine.

 

It turns out that there is a known bug with the Windows Server 2008 R2 and Windows 7 64 bit disks on EFI machines.  There is a line in the properties of the ISO that does not follow the ISO standards properly for UEFI, and causes a failure.

 

I wonder how many innocent Mac owners out there assume that Server 2008 R2 and Windows 7 64bit just simply can’t install on their machines?  I wonder if maybe it was on purpose, hmmm?

 

Anywho, I used Jowie’s instructions, which require you to dowload and use a freeware/shareware version of imgburn to create a different ISO, minus the bug, and burn it.  Then that new ISO is good to go for any EFI product.

 

If you prefer a command line, non-third party work around, try using "oscdimg.exe -n -m -bd:\boot\etfsboot.com d:\ c:\windows7x64.iso", assuming "d:\" is your cd rom drive where the DVD for the OS is.  I culled this advice from here. 

 

These ISO fixes apply to both 64 bit Windows 7 and Server 2008 R2.

 

With my newly burned Server 2008 R2 iso, I started the install process again.  It started with the boot loader stating that the disk could only support doing a Windows Setup with EMS support,

 

 

 

Then I got the windows loading line,

 

 

Then Windows Started, and I was able to choose my locale/language/keyboard, start the install by choosing my OS, partitioning my drive (I deleted existing partitions, chose the whole drive, was warned that two partitions would be made (one is a device partition, basically a boot partition, the other is the OS partition, containing the OS files),

 

 

 

 

Once my partitions were set up, the installer could easily start installing the OS –the usual expanding files,

 

 

rebooting into the OS itself to continue…

 

 

 

then starting services, completing install,

 

 

preparing the computer for the first use, assigning a password, and setting up the desktop

 

 

And finally, the Server 2008 R2 (RC) desktop appears, all ready to go.

 

 

And there you go.  Now the image is fuzzy, but in the system tray, you can see that internet access is not working (although it’s aware that the computer is using wireless), also sound is disabled.

 

This would lead you to assume that at least the wireless NIC drivers aren’t working, and possibly the sound drivers as well.  They both work (although the sound drivers could use some work), but in the server OS, they need to be explicitly enabled to work.

 

To enable the wireless NIC, go to the server manager, add features, and in the features box, scroll down and select "Wireless LAN Services."  This is supposed to allow the server to be wireless aware so it can provision clients with the wireless connection info, manage them, etc.  But for my purposes, I just want to give the laptop internet access.

 

 

Once that’s done, you will be able to use the wireless NIC for internet access.

 

To enable sound, I just clicked on the audio as if I were trying to turn it up, the OS asked me if I wanted to enable sound, I indicated yes, and there I went.  I had sound.  Not great sound, but it still worked.

 

There were still some problems though.  Just as with the Windows 7 install, I don’t have any right clicking capability or scrolling with my mouse.  Also, backlighting on the keyboard and the extra functions (volume, brightness, etc) for the function keys didn’t work.

 

Time to break out the bootcamp drivers.  But there’s a catch.  The bootcamp drivers that came with my laptop are 32 bit only.  They don’t really work with 64bit windows.  I tried looking online, and this is what I found.  Find someone with a unibody Macbook Pro or newer, and get the BootCamp64.msi file– actually, more importantly, get the drivers that come with the bootcamp file.  If the bootcamp64 file won’t run for any reason (I had to try it twice to get it to work, finagling the compatibility settings, running it as admin, rebooting, etc), you can run the installers for the separate devices– especially the keyboard, trackpad, and isight. Just be sure you’re in the x64 folder.

 

 

 

((My adventures with driver installing was pretty varied and extensive and likely will get their own blog entry in the future))

 

After I installed the 64 bit Bootcamp drivers, I also did all the updates I needed for the OS– which included some nice driver updates for my wireless NIC (atheros), and the firewire 800 device drivers.

 

After an install of all the drivers and updates, I had a laptop with Server 2008 R2 (RC) installed on it, the keyboard, trackpad, audio, network card, video, USB/Firewire, and more all work.

 

So to recap:

 

— You can install Server 2008 R2 on a Macbook Pro.

— Yes, there is a problem with the ISO that needs to be worked around, but the OS itself works on an intel Mac just fine.

— Be sure to use 64 bit drivers.  I found it easiest just to let the bootcamp installer do the work for me (with some hiccups, but that’s more 2008 R2’s problem than the driver files themselves…).

— If you are using a wireless internet connection on your laptop, and you want server 2008 to use it to, you must enable the wireless lan services feature, otherwise it won’t work no matter how many times you reinstall the driver…

 

So that’s it, 2008 R2 on a Macbook pro.  That much closer to being able to do firestarter events. Up next is getting hyper-v to work.  Stay tuned….

 

 

Final post on Windows 7 XP mode, and thoughts about Antivirus software

 

Okay, so this is the last one, promise.

I’d read a post somewhere where someone was speculating about the administrative overhead of having XP mode running on Windows 7.

Yeah, it’s nice to be able to say you have full compatibility with any software that could run on XP.  But that also means you’ve got two operating systems on one computer to keep patched and safe.

Someone had mentioned that it was going to be a pain to have to install two different copies of AV software, keep them up to date, and scan both OS’s.

And that got me to thinkin’…

I cannot access the VM’s drives from the Windows 7 desktop, but I can access Windows 7’s drives from the XP mode VM, right?  So, what if I install Antivirus software only in the VM, but set it to protect the VM, and the mapped drives of the Windows 7 host.

So I installed a free antivirus product (Avast for this example), and set it to scan the local VM’s C: drive, and the host’s C: drive.

And then I ran it to scan for viruses.  It scanned the local VM drive without fuss, and then went on to scan the mapped drive as well.

I could also work easily in Windows 7 during the scan without any particular lag.  Of course, Avast doesn’t have that much in the way of administrative settings, but it at least can be scheduled to run a regular antivirus scan on mapped drives.  So, in that case, in terms of scanning, it does seem as if one copy of AV on the VM can do the job of two.

Of course, there are caveats.  1) You always have to have the VM running.  But as the Virtual Apps don’t actually close or shut off the VM when they close, it well may be running anyway. 2) If real time protection doesn’t work between the Windows 7 host files opening, and those opened from the VM. In that case, you’re going to need a copy on the desktop as well as the VM if you want preemptive protection, rather than after the infection scanning. Something else to consider is it might be hard to infect files from the Windows 7 desktop to the files in the VM, but because of the file integration features, I bet the VM can infect Windows 7… something to bear in mind if you are considering not using AV on the VM because users won’t really be opening it directly after you set up their virtual applications…

Something else to think about is Microsoft is coming out with Microsoft Security Essentials, basically a reworked One Care.  I wonder if they might consider offering it as an AV solution, gratis of course, with their gratis copy of XP SP3?

Regardless, in case of emergency, you can definitely scan the Windows 7 files from the VM, but not vice versa.

Just something to think about in the “twice as much" administration” debate.

An almost final post on Windows 7 and XP mode—How to get W7-non-compliant devices to work anyway…

Howdy all.

As you know, I’ve recently installed Windows 7 on my Macbook pro to see if it would work without bootcamp.  And, lo and behold it did.

And XP mode worked to.

But, before I wipe it and install Server 2008 R2 (to see if I can), I wanted to show you one more thing (or two).

While I was messing with Windows 7, and particularly, the Macbook pro drivers in Windows 7, I came across the fact that, no matter what I did, I could not get the camera or its iSight.inf file to work.  Windows 7 just wouldn’t accept it.  I mean, it knew the iSight was an iSight, and not some generic device, but it couldn’t, for some reason, read the inf and install the correct drivers.

So what’s a girl to do if she wants her iSight built in camera on her laptop to work if she’s got Windows 7 installed?

Why, use XP mode, that’s what.

You see, I mentioned some interesting stuff about XP mode earlier, but I didn’t really go into the USB support setting.

As you know, the XP mode VM has some interesting new settings in comparison to Virtual PC VMs in the past, namely RAIL QFE features, like login credential saving, auto publish, and device sharing (like printers, smartcards, or drives).

But what I didn’t go into was USB.

In the VM window,

under USB, is listed the USB devices identified on the host Windows 7 machine as available—even if they don’t work in Windows 7.

I knew that the reason I couldn’t get the “unidentified” USB iSight to work in Windows 7 is, no matter what I did, I couldn’t get it to use the isight drivers.

 

But I also knew that that driver worked fine in XP.  So I copied the driver folder over to the desktop of the VM.

Then attached the “Unidentified Device” in the VM. Both Windows 7 and XP bonged a bit (when you attach a device to a VM is detaches, essentially unplugs, from the host, and XP immediately identified the device as an iSight. It still showed up as a generic “USB device” in the devices window though.

 

Now that’s a good start, but it still didn’t quite work. When I opened the USB device, it just showed an empty box where the video should be.

So I went into Device Manager, and updated the driver for the device,

and then it worked.

Now that’s cool in the VM, but how about the Windows 7 desktop?  Well, if I go to the virtual applications list in the Start Menu, and click on the Scanners and Camera Wizard link,

(I’ll have to close the virtual machine of course, which by the way, tries to capture the mouse and interrupt whatever else you’re doing while it’s at it), the window for the iSight opens right up.

Now, if use the MSN Messenger built in to XP, I can do video chat without a problem.

And, surprisingly, now that I have it working in XP mode, I can now google chat with the camera in Windows 7, despite the fact that it didn’t originally work without the VM.

Weird?  Yes.  But the whole thing is in beta, so I guess a bit of odd, inconsistent behavior is to be expected.  But maybe that means my iSight will be able to work without issues in the future (and therefore I won’t need to run it in the VM after all).