We are seeing an annoying and bizarre problem on machines after going into Audit mode and that continues on to deployed machines. We are working with a pretty bare bones setup, so we don't see how it could be something we've done wrong. Here is the process we are following which produces the problem:
- New install of Win7 x64 (Pro or Enterprise).
- Check that PowerShell and MMCs (Computer Management, Device Manager, etc.) start as expected regardless of CD/DVD status.
- Put machine into Audit Mode.
- PowerShell and MMCs (Computer Management, Device Manager, etc.) start before any CD/DVD inserted.
- Insert ANY readable CD/DVD and let windows "see" it.
- Eject the CD/DVD.
- When either PowerShell or any MMCs are attempted to start, a retry/ignore/cancel window pops up saying, "There is no disk in the drive. Please insert a disk into drive D:." Neither Cancel nor Ignore work, and the task manager cannot get rid of the window either. The only solution is to insert a disk (any disk) and then everything works again. As long as the machine has not been restarted, this problem continues; No PoSh or MMCs unless a disk is in the drive although removing the disk while they are running has no effect.
An example system log entry is only information level and simply says:
- Application popup: CompMgmtLauncher.exe - No Disk : There is no disk in the drive. Please insert a disk into drive D:.
This is driving us crazy - especially since we can find nobody else who has mentioned it. Could someone confirm this happens to them?
Is this a bug or have we done something wrong? Can any guru here offer some suggestions as to a proactive or reactive solution?
Thank you for your question.
I am trying to involve someone familiar with this topic to further look at this issue.
TechNet Community Support
Thanks for the reply.
Since my first post, we have installed plain-jane Win7sp1 x64 on a physical machine (we were on a VM) and with no additional software and no changes, verified this same problem. Once Audit mode is enabled, PowerShell and MMCs will not open without an optical disk available once one has been inserted.
If this exhibited itself only during Audit mode, it would hardly be worth mentioning, but since it continues on after machines have been sysprepped and deployed, it drives some people crazy.
Although I'm pretty confident it's not just us, I would still love to hear a confirmation from someone else.
Please check if you have a removable drive configured as drive letter D. If yes, please change the drive letter assignment for the removable drive to a letter other than D.To change the drive letter assignments, follow these steps:
- Log on to the computer as Administrator.
- Insert a disk in the removable drive.
- Click Start, right-click My Computer, and then click Manage.
- Click Disk Management.
- Right-click the partition, logical drive, or volume that you want to change, and then click Change Drive Letter and Paths.
- Click the removable drive, click it, click Change, click the drive letter that you want to use, and then click OK.
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
This is a rather cheesy workaround as long as the drive letter remains not D. Set it to E: and the problem is gone. Set it back to D: and it returns though, interestingly, the disk instert/eject status is reset.
I'm not sure I can say this is a real solution, but it's a step. (And still no confirmation from anyone that they can repeat this.)
Do you have any information as to why this is happening? Is it related to the assigned letter of the installation drive? Is there a registry key or INF somewhere that can be modified to change the problem drive letter? It would be best to not have this crazy problem in the first place, but if I could make the drive "B" be the "dangerous" drive, nobody would ever see the problem.
I had a very similar experience with my build process. As part of the build, I would try to run the PowerShell script that I found. Google 'InstallWindowsUpdates.ps1' and 'Tony Murray' and you'll find the script. Only problem was that it would throw that "There is no disk in the drive" error when I tried to run it. Upon rebooting, PowerShell would run the script. For awhile I was resigned to this, thinking that it was a quirk. Recently, I decided to revisit the script and wondered if there was something I was missing. It occurred to me that the error would only happen if I finished copying files from either a CD or a USB drive. I resolved from that point onward to make certain that I rebooted after doing any file copies. Also, I made one change to the script - instead of pointing to, say "C:\Patches" as my source folder, I used "$Env:SystemDrive\Patches." The next time I worked on a build, I made sure that my folder was in place and that the script was on my desktop. I then rebooted the PC. After clearing out the Sysprep window, I right-clicked on the PowerShell script on the desktop and launched the script. It ran - no warning errors at all.
See if any of this helps.
Thanks for the suggestion, but it is definately not a script issue.
Once you have inserted a disc and then ejected it, not only can you not run ANY .ps1 script, you can't even open the PowerShell console. You also can't open any MMCs including a blank one without any snap-ins loaded.
You also don't have to reboot. You can either insert any disc back into the optical drive that previously had one, or you can change the drive letter of the optical drive and then change it back.
A reboot isn't necessary - see above.
However, this is an odd issue. I haven't tried it, but I'm curious if the "problem" drive letter is always assigned to D:, or if it is tied to the installation drive.
If the problem always ends up as D:, then either it is a distinct, hard-coded bug/bad design, or there is a setting (probably in the registry) that could be changed to eliminate the issue.
If the problem drive letter is due to the installation drive, some creative possibilities arise. Installing from a drive letter like I: would likely lessen the chances of running into the problem. The obvious, nearly fool-proof work-around would be to somehow install from the B: drive. Nobody would ever encounter the issue that way, but I'm pretty sure it's not possible to install from B:. Can anyone confirm that?