To resolve the issue, boot into Windows RE (stands for Recovery Environment). When you reboot the server, you’ll get two options. One to “Start Windows Normally”, the other says “Launch Startup Repair (recommended)”. Choose Startup Repair. After entering the local Admin password (which on Domain Controllers is the AD restore PW), you’ll see a Window with a few options. Click Command Prompt to open a DOS prompt Window.

At the DOS prompt, DIR C:. You will probably see volume information that says System Reserved and no files. If you do see a Windows directory on the C: drive, then you probably do not have the problem described in this article.

At the DOS prompt, enter REGEDIT. This will open the Registry Editor. Browse to HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices. Look for the values named \DosDevices\drive letter:. We need to find the boot partition’s drive letter. It will usually be assigned the first available drive letter after C: From the command prompt, perform a directory listing of each drive letter after C: until you find the drive with the \Windows and \Users directories. This is the real C: drive. Note its drive letter.

In Registry Editor, rename the value \DosDevices\C: to \DosDevices\J: (or any other available letter). Next rename the value representing the real C: drive to \DosDevices\C:.

Reboot your computer and you’re all set. We still attempting to determine what’s causing this, but following these steps will get a Windows server having this issue up and running promptly.

Bill Gross, Technical Services Director
MCSE: Security, RHCE, VCP4
IT Solutions Consulting, Inc.
http://www.itsolutions-inc.com

8/9/2011 Update:

We still have no idea what’s causing this issue, but it’s happened on a few more of the domain controllers we manage. Fortunately, using this method we’ve been able to get them up and running pretty quickly. That being said, I discussed this with a colleague, Mike Brehm, who pointed out that when I run regedit from the Recovery Environment, I’m actually editing the Recovery Environment’s registry, and not the Windows installation’s registry. (The Windows installation’s registry can be opened by running a reg add command). The server Mike was working on was not fixed by the Regedit trick, instead he booted into AD Restore Mode and reinistalled VMware tools. That resolved the issue in his instance. Other servers experiencing this problem have been fixed, at least temporarily, using the Regedit method, though sometimes the engineers implementing the solution had to try it a couple of times. I used the fix on two servers, it worked the first time on both, but the issue did recur on one.

So, we now have an intermittent problem of unknown cause, that can apparently be resolved by a trick that, based on our understanding of Windows, shouldn’t work.

All servers experiencing this problem have been Domain Controllers running Windows Server 2008 on ESX and ESXi 4.1. So, maybe it is does have something to do with a VMware driver, and reinstalling VMware tools is a true fix, and whatever happens with my registry fix is pure luck.

yes. this is a real photo

Yes, this picture is real. Not bogus. That is Windows 7, running on an iPad. Now, if only we could get OS X to run on it. Oh, the irony…but I digress.

But for those people working in IT who have been trying so desperately to convince themselves that they actually NEED an iPad, this may push you over the edge. This screengrab is basically an iPad running an application called the Citrix Receiver which connects to an updated version of Citrix’s XenApp, and into Windows 7. Voila. Multitasking is officially on the iPad–but the irony is so thick here. It’s brought to the iPad only by using Windows on it. How could Steve Jobs think for once that this wouldn’t happen? How could he leave such a gaping hole in functionality on this device that has been specualted about for the past 3+ years by IT pundits and fanboys alike? No matter. It’s left for another blog post elsewhere. The real point here is that this thing might ACTUALLY be usable for IT folks around the world.

In my particular role as a Consultant/Engineer, it’s already been brought up in talks with some of our clients in the Medical field. Doctors LOVE tablets. They love the idea of strolling the halls on rounds being able to literally tap their reports into the system in a ultra-sleek, fully-functinoal, sexy, and paperless fashion. Until now, tablets have always come up short in at least one of those categories. And the thing is, the iPad comes up WAY short as well. (Not in the ‘sexy’ category, mind you, but just in the ‘functional’ one).

Citrix has been developing the XenApp update for the iPad for quite some time now. It’s almost as if they were working WITH Apple to bring forth the functionality; which wouldn’t make a lot of sense on the surface. However, looking further, it’s yet another glimpse of Jobs’ Genius. Apple gets to market its iPad as the iPod Touch’s Steriod-laden big brother, touting ‘simplicity’ all along the way. Meanwhile, they allow the development of a 100% integrated support for Citrix, which then brings a full-fledged SysAdmin weapon to a company’s IT organization–granted there are adequate WiFi support. Doctor’s can now walk down halls touching to their heart’s content, and looking good while doing it. Zoom around the Fisher-Pricey but gorgeous iPad interface one moment, then boot XenApp and slip into a Citrix session running Windows 7 (plus multitasking) the next. Apple has quietly reached the pesky IT demographic for the iPad.

Actually, there is a public report now of a medical facility in Oregon that has already offically begun a rollout of about 5 iPads using the Citrix Receiver to run Windows 7 and NextGen EMR application. Do not forget–the iPad was released less than a month ago.

Citrix has already put the demo video on their website of the Citrix Receiver for iPad. iPad Citrix Receiver
Which speaks volumes–seeing is believing.

As a fanboy who has posted here before about Apple, I had no inital interest in the iPad. I have an iPhone, and this to me was just an expensive toy with functionality that was severely lacking. When asked by my peers not long ago about Citrix’s ability on an iPad, I quickly scoffed at the idea saying it wouldn’t work. Urged to open my own mind about the idea, I did my research. And while I will stand my ground about the iPad’s functionality natively leaving much to be desired, as an IT professional I cannot be short of bouncing in my seat when I see this Citrix capability to run a Windows desktop over WiFi or 3G (hopefully, 4G soon). And with the announcement of iPhone Software v 4.0, which DOES do multitasking and folder support, I can only think that the iPad will get better very soon, allowing us to run Citrix/Windows session WHILE we oh-so-elegantly zip around the sleek native apps on the iPad such as eBook reader, custom You Tube and eBay apps and the like.

The iPad might be in my sights after all. And, it might as well be, since I can easily see this as a tool to be adopted by enterprise organizations everywhere. Be Prepared.

Now, if we can only get Apple to move to Verizon…

• Most users on Windows that I know, run their applications maximized.
• OS X users tend to have their windows open as large as they need to be to see the content, but no larger.

OS X is the more forgiving of the two for a Filemaker developer. Usually you just open the window and adjust to fit the content, and you’re done. You’re not likely to need to adjust the window again (unless you have large differences in layout content size). If you don’t maximize, Windows users aren’t likely to enjoy or understand the extra grey space in the gap between the Filemaker application window and the database document. When the user decide to maximize on their own it causes problems. If you haven’t accounted for this possibility when building your app, the user is going to become annoyed when new windows are launched and undo their maximization over and over.

The alternative is to maximize the window and assume they will always be maximized. When opening new windows that are not maximized, the main interface window is restored to whatever size it was before being maximized. When closing your pop-up window you (the developer) have to re-maximize or restore the previous window size. Even though it’s the logical way to deal with the problem, it looks sloppy. Especially when compared to the way things work on OS X, where there is no layout adjustment needed for a pop-up window.

There’s another option that you may not have thought of. I didn’t think of it either until recently. I had the need to run an install on timer script to open a window and grab some data periodically in the background. As soon as I opened the solution in Windows the problem became very apparent. Whenever the script runs, the window un-maximized. I could always add a step to re-maximize, but again; inelegant. What I decided to do was to fake maximize the window when the file opened. I’d keep the window un-maximised , but fill as much of the Filemaker application window as possible, using the Get ( WindowDesktopHeight ) and Get ( WindowDesktopWidth ) functions. This will tell you how big to make the window. I’ve found that subtracting 4 pixels on each dimension will make the window size just right.
Fake Maximizing a window in Filemaker
Now, no matter whether the user has the Filemaker application maximized, or only taking up part of the screen, the internal document window will be adjusted to fit just within the bounds. This makes the windowing more consistent cross platform. Users who habitually maximize probably won’t feel the need to since the window will be taking up all available screen real estate (less the extra space needed for the document title bar). Enjoy. WindowsMaximizeFakeout Demo