Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!
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.
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….
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!
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.
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).
In the previous episode of the series, I finished up tweaking the drivers in Windows 7 by using bootcamp 2.1. It worked for most issues, and what was left was pretty minor (intel chipset installer didn’t like Windows 7, nor did the inf file for iSight drivers, and bluetooth is flaky). I also remapped the keyboard in preparation, not that it helped.
So, armed with a working installation of Windows 7 on a Macbook Pro (sans Bootcamp), it’s time to see if I can get virtualization to work.
So in this entry we are going to explore installing and using Windows XP mode.
This “mode” has been much lauded by Microsoft as the way to get around the fact that a lot of software that runs fine on XP or earlier Microsoft OS’s, just absolutely, positively, cannot run on Vista or Windows 7. Important, custom business apps perhaps, accounting packages, or just much loved media programs that simply worked, and worked for years. Products that won’t ever be upgraded to work with Windows 7.
Good reasons all for not moving to Windows 7.
And Microsoft doesn’t like that, but has no choice but respect their customers’ need for these applications, despite the fact that they’re not made or sold by Microsoft. Shocking…
So Microsoft has decided to allow one free copy of XP SP3 to be available as “XP mode,” run in a virtual machine for people who purchase and are running Windows 7 (professional and higher of course, home users, for some reason, don’t get to use it).
All of this is basically old news at this point, except for installing it on a Mac.
You see, the requirements of XP Mode, in addition to those required to even install or run Windows 7 as the host, are:
– Windows 7 RC
-Additional 1GB of RAM (although the VM itself is set to use 256 MB by default…)
– Additional 15GB of available disk space (although the VM’s hard drive only takes about 1.6GB from the start)
-Processor capable of hardware virtualization with AMD-V or Intel VR turned on
|
**To check if your processor supports virtualization, use the Processor ID Utility. The Intel version is available at http://www.intel.com/support/processors/tools/piu/, and the AMD one here, http://support.amd.com/us/Search/results.aspx?k=AMD%20processor%20check (it’s the first link). I have an intel processor, so I used the intel one, of course. It was a short download and install, and it ran easily while all kinds of stuff ran in the background.**
** As you can see, it tells me that my processor supports virtualization, but apparently you may also need to configure the BIOS to enable it on some computer models. This is why I am just trying it out, because I can’t get into EFI on this machine to configure anything. For more detailed info, go to the Virtual PC website: http://www.microsoft.com/windows/virtual-pc/support/configure-bios.aspx.** |
Please note that last item—a processor capable of virtualization.
Hmmm, I wonder why? Frankly, to skip ahead, all XP mode is: Virtual PC (currently version 6.1.7084.0 and seriously gimped), with XP SP3 installed in a VM, and with “integration features” (which are something called RAIL QFE, and offers device support, like printers and drives, USB pass through, and auto-publish) in that VM.
Now honestly, I can’t really see how Virtual PC (even using the fancy new integration features) requires a processor that supports hardware level virtualization. But whether or not it’s used, it’s listed as a requirement…
| **RAIL QFE (no I can’t seem to find info anywhere as to what the letters actually stand for), is a package that can be installed into any VM running in Virtual PC to allow it to integrate like the XP Mode VM. Currently there are QFE packages only for XP SP3 and Vista SP1.** |
Anyway, here is a summary of my adventures with installing and using XP Mode on Windows 7.
To start, I didn’t have to download the XPM (as they abbreviate XP Mode at this point), I got a copy on DVD at TechEd.
XP Mode actually requires two installs: one of Virtual PC itself, and one to install XP SP3 into the VM.
The Virtual PC installer is actually treated like a software update (don’t ask me, maybe they don’t want users easily uninstalling it). It comes in two flavors; 32bit and 64.
If you run the installer of your choice (I’m on a 32bit version of Windows 7, as you may remember), it will trigger a popup warning you that you are installing an update. When you click Yes on that, it, of course, prompts you concerning licensing, then installs the “Update.”
And of course, like most Windows updates, after install it requires a reboot (so be ready for it).
After reboot (and during this part I did get distracted by the loss of one of my sidebar gadgets, and the gadgets gallery, but that’s a known problem and neither here nor there…), I checked the Start menu, and lo and behold, there was a Virtual PC folder, with a XP VM already available.
And, being me, knowing full well that there was a second half to the install that I hadn’t completed yet, I had to try to run the Virtual Windows XP virtual machine. And, if you do that, you’ll get a dialog box that says:
Notice that it doesn’t let you OK out of the dialog box. The OK has been replaced with “Download,” so you can download the XP installer if you don’t have it already. Kinda convenient, no? So what did happen during the Virtual PC install? Virtual PC and the menu items for more. Yeah, that’s it. The virtual machines (a parent disk will be created by the way, and the VM you’ll actually be using will be a child disk) will be created with the XP mode install. Why a parent and child? Dunno, just cuz.
Knowing now, for certain, what the second installer is for, let’s use it.
It comes in two flavors as well, depending on your architecture. So use the one that’s right for you (I’m using the x86 one).
When you double click the installer of your choice, it strangely informs you that it is installing Virtual Windows XP. I think that MS isn’t entirely clear on how they’re going to surface this feature— but Virtual PC has been installed as an update, and the copying the parent XP SP3 VM, then creating a child VM of it is being treated like a normal install. I guess they thought the intended audience didn’t need that kind of detail.
Next, it will ask you where you want to put the virtual hard disk file. What it doesn’t tell you is you are going to only be specifying where the parent hard disk file will be going. It does not mention the fact that the real virtual disk you will be using for you XP mode files will be located under your user account on the C: drive. That’s the file that gets really big. As I am just testing this as a proof of concept before moving on to install server 2008 R2, I am just keeping the default location.
Next, after specifying a (or accepting the default) location for the files, it’ll start unpacking and creating the parent virtual hard disk for XP.
After the parent disk for your XP mode VM is created,
you can launch Virtual PC, which will then move on to setting up the real VM for XP mode. As far as I can tell, it basically creates a Virtual Machines folder in your user profile, under my documents, then it creates a child disk there off the parent disk. The parent disk seems to be sysprepped to run a mini setup, because it prompts you to accept the EULA, set up Automatic Update, and set a password (we’ll get to that in a moment).
Then it moves to setting up the machine for the first time, and starts the OS.
Then it does something interesting. Rather than waiting until I get to the desktop of the virtual machine, and then leaving me to install the virtual pc integration features, it just does it right there (because auto-enable integration features is pre-set in the settings of the VM during creation).
Now, these features are pretty extensive for this version, so it will take a while. During this part you will be prompted for the password you set up for the VM earlier (unless you enabled cached credentials).
But once the integration features finish installing and “enabling”, you’ll get to the Virtual Machine’s desktop.
Tada!
XP mode works in Windows 7 on a Macbook Pro. Now, I could take that as a sign that virtualization is supported by the Macbook pro’s processor, and set up in EFI, but I don’t really trust that Virtual PC really uses it. We’ll see. At any rate, so far this worked.
As an administrator, I always check to see what has changed in the OS as a result of any installation. And, as you can see, the child disk, the one running, is now located on the C: drive in my user profile under C:\Users\callahan\AppData\Local\Microsoft\Windows Virtual PC\Virtual Machines. So that’s where the XP Mode disk file gets put, regardless where the, ultimately, smaller parent disk file is located.
And, now that I’ve got the machine up, I wanted to see what it’s settings really were, since I didn’t get any choice in the matter during installation.
For one thing, this virtual machine window has far, far fewer settings in the menu bar than ever before. Most notably, there is no hot keys for ctrl-alt-del. It’s a menu item, that’s it. There is no option, in the menu, for creating a new virtual machine (nor does a little console open for you do to so). There is an intentional feel to how little administrative control this interface offers—as if the user is not really supposed to know that there is a separate application available to manage and create virtual machines that is powering their “XP mode” virtual desktop.
| ** although, if you did want to create different virtual machines, other than the one that comes with XP mode, making use of the virtual pc software, you can run the create a new virtual machine wizard under C:\Windows\System32, using VPCWizard.exe.**
|
To see what settings have been configured for the VM, click on Tools, Settings…
This will bring up the standard Virtual PC settings dialog box (there doesn’t seem to be anything there about saving state, it simply does). Of note were the location of the VM’s hard disk (in C:\Users\callahan\AppData\Local\Microsoft\Windows Virtual PC\Virtual Machines\Virtual Windows XP 1.vhd). And the parent disk, located at the place specified during installation (the default is C:\Program Files\Virtual Windows XP\Virtual Windows XP.vhd).
Also to consider is the teeny, tiny little bitty amount of RAM alotted to this VM. The point of XP mode, if you remember, was to let users install and run applications that could not run on Windows 7. And all this VM gets by default is 256 MB of RAM. That’s it.
So if you hear complaints about how honking much RAM someone’s computer has, but their XP mode applications run crazy dog slow—well, that 256 MBs of RAM might be the culprit.
And keep in mind that, at this point, there is no mechanism for changing that setting. The only way to get to the settings is to have the VM running. But to change the VM settings, you have to have the VM shut off. (and yeah, in System32 there is a VPCSettings.exe file, but I’ve tried running it, and it does not work when the VM is off, only when a VM is open, and only for that VM).
So the only way, I’ve found so far, is to actually edit the VMC file for the child disk itself (NEVER edit the VMC of the parent disk, or open that disk- which is read only for a reason).
| ** Note, at this point, the XP mode VM is very, very fragile. Do not edit the VMC unless you need to. If you do, it may reinstall integration features when you restart the VM. If they fail, the VM is pretty much hosed. Also, while I’m on the subject, XP has never been crazy about hibernation, which is what the VM here is set to do whenever it closes. After about three closing and openings, the VM corrupted on me and I had to reinstall the XPmode portion of the process. It takes a while for the VM to start up, but if you can afford the delay consider changing the Close setting from Hibernate to Shut Down (or turn off even, if you want). It seems to help me avoid VM corruption. You have been warned.** |
There are a few new settings available to this version of Virtual PC VMs that were not available in earlier version, such as being able to disable or enable (even auto-enable) individual integrated features,
Login Credentials (if they’re saved for the VM, they’re always used at startup, rather than delaying the display of the desktop—it is also useful to make the running of virtual applications seem seamless, but I am getting ahead of myself), and something called “Auto Publish".” Like Unity in VMware, it allows applications used in the VM to be run on the host. It does this by using a gimped form of terminal services to RDP into the VM and pull up the application as if it were native. There are some pros and cons to this, which I’ll cover later.
The whole point of having XP mode is so that users can use applications that are incompatible with Windows 7 on a Windows 7 workstation. This goes a little way towards explaining the default setup of the VM’s settings, and the lack of real administrative control. Their focus audience seems to be users who actually aren’t going to really be using the VM, but instead, need to be able to use said applications right on the Windows desktop like they were really installed there.
The way to do that is invoke Terminal Services— and that’s what XP Mode does. That’s what the “Virtual Windows XP Applications” option in the start menu meant, it’s going to list “virtual” applications that will actually be running in the VM.
It’s also, interestingly, related to how the VM “shares” drives with the host.
On the Macbook, I have the main C: drive with one big partition for files, a DVD drive, and an external hard disk. This is represented in the VM as mapped drives.
Now if I open, say, the mapped C: drive,
you can see in the address bar that it’s simply the mapped C: drive address. But if you actually open any of the folders (there will be a lag), the path changes to “\\tsclient\C\Windows”
The tsclient being the person you are actually logged in as on the host, which I proved by being unable to open a different user’s User folder, but being able to open mine.
So terminal services is being used. This being so, then it stands to reason that I’m logged into a console session of the VM. If anyone wanted to use RDP to access it, I’d have to be logged off of the VM, and they’d need to be logged on. Because that’s how remote desktop/terminal services, works.
Keep this in mind.
Now as I mentioned before you can use “Auto Publish” to access applications from the Start Menu of the Windows 7 host desktop. This means that most applications that you install into the VM can be published to the start menu for “all users” in Windows 7.
| ** I’ve been messing with the VM, and was trying to get the built in iSight camera to work in the VM (which I’ll get to later), so Scanners and Cameras will already be available, interestingly, when I check out the Start Menu. Also, as I mentioned above, I’d crashed the first XP Mode VM due to hibernation issues, so I actually have two sets of Virtual Application menus. I am going to, obviously, use Virtual XP 1 (the second one I made) because it’s the one that works. Note that, after uninstalling XP Mode so I could recreate the child VM again, it didn’t delete the listing for the now defunct original VM (nor delete the VM itself of the drive, mores the pity) in the Start Menu. I can see this causing issues with users—let’s hope they fix this issue before release.**
**Speaking of the iSight camera, I will be writing an entry about how to use USB devices in the XP Mode VM that won’t otherwise work on the Windows 7 machine. It’s kind of cool actually.** |
To keep it simple, I’m going to install Word Viewer in the VM and see if it shows up in the Windows 7 start menu.
When it finished installing, I opened Word Viewer just to be sure it worked (another administrator habit). Then I went to the Windows 7 desktop on the host, and under the Windows Virtual XP folder>Virtual Windows XP Applications (well, in my case Virtual Windows XP 1 Applications, since I crashed the original), is the Word Viewer I installed in the VM.
(I included the popout in the screenshot because it clearly shows that the app is actually in the virtual machine.
When you run the word viewer, it will display outside the VM window, but it still runs in the VM. This means that, if I have the VM open (and therefore be working on the console, so to speak), I will have to log off of there, and then log in to the VM while opening word viewer in order to access it.
Now you can see why saving your login credentials for the VM in the settings of the VM itself becomes useful. The user, namely myself in this example, won’t have to log in when opening the virtual app when it’s opened, making it seem seamless. However, this is a serious lag to opening any virtual app, especially if the VM is actually shutdown and not running.
To run the virtual app, click on it in the start menu. If you have the VM running, it will trigger a dialog box (in the VM itself), asking if you want to close the virtual machine. This is misleading. The virtual machine will not close, it’s still running. However, the window, or more precisely, that console, will close, you’ll be logged off of it, and then, the tsclient using the virtual application will be logged on using the saved credentials in the settings.
So if you choose to close the virtual machine (which you have to to run the virtual application), it logs you off the console.
And rapidly (because the VMs still running, and credentials are stored) opens Word Viewer on the desktop of Windows 7 host as if it was locally installed.
It looks like it’s running in Windows 7 (except for the format of the Open dialog box, and the title bar is not formatted in aero glass) and not in a VM. It’s accessing the My Documents folder of the Windows 7 laptop, not the one in the VM (slick that). There is a slight lag whenever I open folders, save files, or even close the application—because it’s actually have to pass information back and forth into and out of the VM.
Notice, in particular, that the icon on the taskbar for the Word Viewer is the Virtual PC icon, with a circle with two opposing arrows.
Also, if I do try to open a file in the Word Viewer, it doesn’t show the real file system, but the one from the VM, with the host’s C: drive mapped.
Interestingly, now that Windows 7 knows there’s a Word Viewer somewhere, if I open any file with a .doc extension, it automatically opens Word Viewer virtual app. Now I wonder if that will cause users any confusion in the future…
There are two more things I want to mention about Virtual Apps. One is that if you want to run something that is already installed on the VM as a virtual application, say IE 6 (yes, despite being XP SP3, the VM is running IE6), you can do it. You see, anything in the “All Users” start menu in the XP mode VM is added to the Start Menu in Windows 7.
So to add IE6 (or anything else on the VM) to the virtual apps start menu, open the All Users’ Start Menu folder and add a shortcut for it.
| **This means opening up the console again, which may trigger a warning that you need to close some running virtual applications. Interestingly, the TSR warnings in the VM’s system tray, like updates or security warnings, also get ported to the Windows 7 desktop along with the opening virtual application. So if you close the virtual application (in our case, the Word Viewer window), those TSR’s still remain open, keeping the remote connection between the desktop and the VM open. Could this be wasting valuable resources all the while? You be the judge.**
|
That will immediately put the shortcut on the start menu on the Windows 7 host.
And, if you click on it, it will (after closing the VM of course) open IE6 right on the Windows 7 desktop. A little blast from the past.
The second thing I wanted to mention is that, no matter how hard you try, there can be applications that XP mode refuses to add to the virtual applications list on the Windows 7 start menu. Things like the media player on the VM. Maybe you want to use that version instead of the one that comes with Windows 7.
But if you try to stick the shortcut to it into the All Users start menu folder on the VM, they don’t show up in the Windows 7 start menu, no matter what.
(yes, I did add OE to the start menu, just to see if it worked, but that’s not the point of this particular exercise… but it does prove you can have email locally if you absolutely have to)
So what do you do to if you want media player or one of the other apps that just don’t seem to want to show up in the Windows 7 start menu? And why does this happen anyway?
Well, it’s because, on the VM (not in Windows 7), there is a block list in the registry. This list has on it the programs that XP mode will not allow to be virtual applications. This was, supposedly, to keep redundant copies of things like notepad, workpad, or calculator, from ending up on the Windows 7 start menu.
So if you have something you want to add to your virtual applications list in Windows 7, and it’s being blocked go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtual Machine\VPCVAppExcludeList in the VM itself and remove the blocked application from the list (you can also add ones if you want).
Then the application will appear in the virtual applications list in the Windows 7 Start Menu (the VM will have to restart of course).
And there go. XP mode will install on Windows 7 running on a Macbook Pro. It will configure and run the VM, and even the virtual applications run as expected. XP mode is a little buggy, in my opinion, but it is a beta product running on a beta (albeit release candidate) operating system.
Still, all in all, not bad.
Next up, an entry to finish my adventures with Windows 7 on a Mac—Getting iSight to work in XP mode, because the drivers will not work in Windows 7. In otherwords, how to get your old USB devices to work on Windows 7, despite Windows 7, if you know what I mean.
Stay tuned.
In the previous episode of this series, I went step by step though how to install Windows 7 on a Mac with an Intel processor.
It was easy. There were a few differences, but overall it was no big deal.
So in this entry, I am going to continue from the point of Windows being newly installed on a Macbook pro.
As I noted in the previous entry, although a great many things were working, the mouse and speakers were not, and the video was a little clunky because the drivers were generic.
Now, Apple does have some Windows XP/Vista drivers for their Macbooks, through Bootcamp.
And that means that the manufacturers of a lot of the devices in the Mac have drivers for Windows of some sort.
And that means I could, painstakingly, figure out what each device name, make, model, and manufacturer is, go online, find the right drivers, and download them, then update the device drivers for each device manually.
Or I could just install the latest rev of bootcamp and see if that works.
Which is what I did.
But before we go any further, lets back up and see where we are.
At the desktop, I noticed that the icons were a bit big and clunky. Opening up the Screen Resolution dialog box, I noticed two things:
1) The resolution was quite as high as it could have been.
2) The driver for the display and video card were both the generic, standard drivers. Not the ones specifically for the Mac.
Another thing I couldn’t help but notice was, to get to the screen resolution, I had to go to the control panel. Why? Because I couldn’t right click the desktop and just choose “Screen Resolution”. And, while in the control panel, I couldn’t scroll.
Why? Because the mouse drivers, or more specifically, the trackpad drivers (since I’m using a laptop and not an external mouse), were the generic ones and were missing the features that made right clicking and scrolling possible on the Mac.
Finally, I noticed that, when I did do something wrong on the desktop, I didn’t get any warning sound. That is because the audio drivers weren’t working either.
So, it became obvious that I needed to update the drivers.
On my Macbook, I use bootcamp to run XP (yeah, that’s right. You got a problem wit dat?). To get the trackpad, video, audio, etc. to work, I used the bootcamp drivers. There were some imperfections, like not being able to tap to select, or double tap to open with the trackpad. But still, things worked for the most part.
Therefore, it seemed to me that the quickest way to install the Macbook specific device drivers in Windows 7, I’d just use the Bootcamp ones.
And I did.
First I googled for Apple bootcamp 2.1 vista drivers. I then opened the Apple download page that let me download the drivers, which got me a BCUpdateXP.exe file (note, I am not going to give you an exact address for the file online, because these things change and you might find an even more recent update than I did. Find them yourself, it builds character).
Then I tried to run the file, which popped up an error saying it was not compatible. To fix this I ran it in XP SP3 mode– and even then it didn’t quite work perfectly—the intel chipset drivers didn’t quite work, but as I didn’t feel I really needed those (because the ones for Windows 7 were newer), I was okay with it. Maybe you could try it with Vista compatibility instead. Lemme know how it works out.
Once I ran BCUpdateXP.exe, my trackpad worked, audio worked, and the video worked so well, I had aero glass. During the installation, it did stop right where it was going to install the intel chipset stuff, saying it definitely wasn’t compatible. I didn’t want to push it, so I stopped there. That could cause problems later if I run into anything that would have been installed in the process after the chipset was.
Like iSight.
The only problem I had was the built in iSight camera would not work. The drivers were there, but the imaging device just couldn’t be found. When I tried to force Windows to see the isight.inf file, it simply considered it empty. No relevant content showed up to select.
Bummer. If I come up with anything better, I’ll let you know. And if you do, please let me know. It’s a bummer not to have iSight.
So now my mouse, video, and audio worked great, but I didn’t have a forward delete button (delete as opposed to backspace, which is all the Mac has on the keyboard). You know, like PCs have. I need that button because I am going to load XP mode, and as that uses a version of Virtual PC, I am pretty sure I am going to need a “Del” button.
That means that I need to reconfigure my keyboard (which is honestly the first thing I do everytime I reload my mac). To do that I download and install the Server 2003 resource kit, because it’s got remapkey.exe in it.
This executable is an easy way to remap your keyboard. It makes it possible to move my keys around, covering less necessary keys with ones you need.
Just download the Server 2003 resource kit and install it (you may need to use compatibility mode, and definitely install it, and run it, as administrator).
Then, on the Start menu, got to All Programs>Windows Resource Kit Tools>right click, run as administrator, Command Shell.
In the Command Shell window, type “remapkey.exe” (minus the quotes of course), and hit enter.
That opens the remapkey GUI. There’ll be two keyboards. Move things around on the top, Base, keyboard, and they’ll be saved as new settings on the bottom, customized, keyboard. Then save (first button on left).
The changes get written to the registry (thus it’s easier to run it as administrator, to avoid any errors), so expect a reboot.
After the reboot, the keys will now work. As you can see, I moved forward delete to cover F12. I generally don’t need that key, so it’s worth it to me. I also rearranged some other keys to my liking, like the right alt key.
Now my devices, such as I need, are working, as is the keyboard. Now everything is set so if I install a virtual environment, I won’t need to be messing with the devices on the host (and possible really screw up the virtual settings of the guest machines).
One more thing that is purely aesthetics. I know, not really my thing, I more about functionality. But while I was exploring glass, I did check out the aero themes (more than background and titlebar colors, themes can cycle and have a range of sounds associated with them too).
I must admit I am seriously digging the “Scenes” theme. The really extraordinary pictures (ranging from delicate to deranged, in a good way), cycle after a certain amount of time (you can set the duration, 30 mins. is the default).
So at this point, the machine is ready to have XP mode installed (and more).
Due to the length of this post though, I think I’ll create a Part 3, and do the XP mode install there instead. That way people who don’t really care about the drivers can read about XP mode, and vice versa.
So please join me for part 3, installing XP mode on Windows 7 while on a Macbook Pro. Stay tuned.
So as I mentioned earlier, I managed to find the time to do some beta testing. On my list of to-dos was to see if Windows 7 and (more importantly to me) Server 2008 R2 could install on an Intel based MacBook pro. Without Bootcamp.
Why? Because I’d heard that those operating systems were going to be able to support EFI (instead of BIOS, which is pretty outdated). And, because I need to be able to use Hyper-V virtual machines on my laptop, while leaving as much of the laptop’s resources available for the VMs as possible. Now, bootcamp is nice, it allows a Macbook owner to partition the drive so that there is one with Mac OS X on it, and another for installing Windows, or Linux, or whatever.
But, that is kind of a cludge. The bootcamp partition is emulating a BIOS, but you can’t actually access it, or make any changes, or anything like that. It’s not using the entire drive, even if you never access OS X, it has to be there. Also, since I couldn’t really access the emulated BIOS, I couldn’t enable virtualization, or even check to see if it was available. In that case, as far as I could tell, I definitely couldn’t do Hyper-V in bootcamp.
So what I wanted to do was install, preferably Server 2008 R2, Windows on the machine natively, then run virtual machines in that. And, particularly, I have been wondering if EFI supports Hyper-V. I read a brief article here, where the author, while doing something else (isn’t that always the case?), needed a hyper-v capable machine and only had a macbook available. He made do, had some glitches during install (natch), but otherwise, hyper-v seems to have worked well.
That’s what I want because I’d like to do a firestarter event or two in my town, and I need to be able to do their pre-built demos (which are all built for hyper-v).
—firestarter events are Microsoft community events, usually only a day long and free to attendees, that focus on a particular upcoming product to inspire interest and excitement concerning that product. Because firestarters are community oriented, they aren’t overly funded by MS, and therefore are really driven by the presenter who feels it’s important their area or customers get access to the information, so they volunteer their resources and time to find a venue (and possibly a sponsor or two to help out with costs) to present the firestarter material. You can go to the firestarter events site here to see their calendar of events. Or, if I do one or two, stop by this blog for the schedule. —
Before I jumped in with Server 2008 R2, I wanted to try installing Windows 7 Ultimate first. I figured it was a full featured, client OS, that might’ve been made with laptops (and possibly EFI) in mind and would have the easiest install.
So first, I got my boyfriend’s old (and dirty) 15” Macbook Pro, and slapped a Windows 7 RC DVD I’d gotten from TechEd. It is, by default, only 32 bit, but that’s good enough for initial testing. Also, I was pretty sure that the drivers for bootcamp (the only apple drivers for PC I could find) would be easier to work with in 32bit.
To start, for those of you who are not Mac experts (like me), but own one to run Windows on, To get the Mac to boot to DVD when it’s already got OS X installed (keep in mind that it was my boyfriend’s old laptop), hold down the “c” key during boot (and keep it down).
(Please note: All corroborating photos of the install on the old laptop were taken on a mobile phone (I certainly couldn’t screenshot from the Mac during all this). Not all pics will be perfect (and I did wash down the laptop after the install was complete, so please forgive the grimy screen) as they were taken on the fly at a cluttered work surface containing two Macbook Pro laptops running side by side (and a number of external hard drives scattered about as well). So please forgive the fuzziness, I was in a hurry and wasn’t sure the experiment would work. Please keep in mind that this is simply to prove it works, it really happened, and you can do it too.)
Once it starts booting to the DVD, you’ll get a black screen with text. The only choice is to boot with EMS enabled. Select that and the process moves on with Windows Loading files.
Immediately the install will start, with the standard Windows 7 install background (suspiciously so like Vista). It took about ten minutes to go from Copying Files to Starting Windows.
Then, after selecting the base language/currency/keyboard, Setup starts. It asks if you want to do an upgrade install or custom. I chose custom (as the partitions on that machine did not contain any Windows OS’s).
Then Licensing is dealt with (yes, you have to accept), etc.
Then we get to selecting where Windows is going to be installed. That’s where most people stop. In the pictures below, you’ll see, at the bottom of the window, is a warning that Windows 7 cannot be installed on the selected partition. That was the case for every existing partition on the machine (mind you, that machine was only running OS X). They use a “GPT partition style” and we need FAT32 or NTFS.
So, the existing partitions are a problem. This is often where people stop trying to install. What it really means is this; The existing partitions need to be deleted and new ones need to be created that can be formatted in a way Windows can handle. That’s all.
So delete both existing partitions (the EFI partition and the partition used by the OS, disk 0 partitions 1 and 2). Then create a new partition using the New option listed at the bottom of the window. I chose to use the whole drive for my OS (why not?). This triggers a dialog box warning that more than one partition might be made.
If that’s okay (and it better be), then click OK on the dialog box, and two partitions will be created.
Because I am superstitious, I always format the OS partition before installing.
If you are superstitious too, you can format the second partition, or move on to installing windows by clicking next.
It goes back to the Install Windows page (or window, dialog box, whatever). Copying Files had already been done, so the files just need to be expanded. This can take, what feels like, forever.
Don’t give up hope. Then it’ll install features and updates, and boom, that’s all the information they need, and it announces that the install might cause the computer to reboot several times…
… and then the computer reboots.
Remember, this is a Mac, so first it goes “BONG,” then the screen goes grey. Do not panic. Unless you’ve got a OS X DVD in the drive, it will not boot to the Mac OS.
(really, that is grey, trust me)
In my case, the machine sat there for a long time (felt like at least a minute or more), and the fans started running like the CPU was on fire. Just wait, it’ll setting down, the screen’ll go black, and then start booting into Windows.
After that, registry settings will be updated and services will be started.
Then the screen may flicker to black for a second (don’t panic), then you’ll end up back at the install Windows screen, this time Completing installation.
After which you may have to wait a while, DVD spinning, screen flickering (no biggy), then a new screen saying Windows will continue to install after reboot (pretty screen for such a warning really…).
Then, as warned, the computer reboots. Expect the BONG, the grey screen, and a black one. Then you’ll get the standard DOS, “press any key to boot from DVD”. Then install continues with a Starting Windows screen.
Then it moves on to prepare your computer for first use, checking video performance, etc.
Then it’ll popup a quick box saying Windows 7 Ultimate has been installed (I missed getting a picture of that).
From there it’ll move on to setting up Windows. A screen will come up with the Set up Windows box, to add a user account and computer name.
Then you’ll be prompted to add a password. I always add one, and I’ve heard it doesn’t like it if you don’t. Ever cautious, I did add a password for the user account when prompted.
(you are hitting Next at the bottom of each of these installation/setup pages aren’t you? That’s the only way you can move forward, so I’ve been assuming you know to do that. Is that so wrong?)
At this point you’ll be prompted to add your product key. I chose not to enter a product key until I knew the installation would work– and particularly, if the network card would work, since, in my experience, it tries to activate, or at least confirm the key, as soon as it hits a desktop.
(I’ll save you the suspense—not installing with a product key caused no problems. Unlike other OS’s in the past, there were no delays getting to the desktop, no suspicious lags or loss of functionality, so far)
After prompting for a key, the process also has you do the standard stuff like configure your update settings and time and date. But, and here is where it is interesting, there was a new screen during set up: after time and date, Windows 7 sensed my wireless network card and wireless network before the OS even finished installing (I really didn’t expect that with the Atheros network card on the Mac). It prompted me to choose a network and enter the password (you can even set up a hidden wireless network—one that doesn’t broadcast it’s SSID). Finally it has you select your network type (home, work, public).
After these settings, you get a welcome screen, then “Preparing your desktop”…
… and Tada, there’s the desktop, all ready to start work.
And that was it. Windows 7 Ultimate, 32bit, installed just fine on a Macbook Pro.
In review:
Windows 7 will install on an Intel mac.
If it’s got an OS on it already, you’ll need to boot holding down the C key in order to get the machine to boot to DVD.
During the install, you’ll have to blow out the Mac partitions and make ones for Windows.
After that, install is the standard sort, except for when the machine reboots.
On reboot, the Mac will BONG and go to a grey screen like it’s booting into a Mac OS. Be not afraid, this will pass… it will take a moment, and the internal fans might run like crazy, but it will boot into Windows eventually.
When Windows 7 installs, it will find a lot of drivers, my personal favorite being the wireless network card. Enough drivers that it’ll boot into a desktop that actually works. However, there’ll be no sound, even though the drivers think they’re fine. Also, right click and scrolling won’t work on the trackpad.
Overall though, it works well and fast (although I am running on 2GB of RAM).
In part two of this adventure, I will go into how to fix those niggling driver issues (well, the shortcut, works-well-enough, way I did it) to really get the OS up and running. In addition (probably in a Part 3), because virtualization is the whole point of my trying this stuff—I will also go over whether or not Windows XP Mode works in this situation as well.
So stay tuned.
 | cacallahan on Installing Server 2008 R2 (RC)… |
 | Chad Bumstead on Installing Server 2008 R2 (RC)… |
 | Mr WordPress on Hello world! |
| Tim on How I’m spending my summer—or… |
