Windows 7 64-bit: Full-screen 32-bit DOS program

One of the old MS-DOS programs that I need to use won't run on a 64-bit operating system, and I run Windows 7 64-bit as my desktop.  I tried changing all the compatibility settings, but nothing would work.  The next logical step (in my mind) was to run it in one of our Windows XP virtual machines.  Unfortunately, remote desktop (aka terminal services) doesn't have the capability to load full-screen MS-DOS fonts due to performance issues, and this causes the following error message:

The video device failed to initialize for fullscreen mode. Choose 'Close' to terminate the application.

So using remote desktop to access a 32-bit virtual machine was out of the question.  The next idea that came to mind was using a feature of Windows 7 called Windows XP Mode.  This simply creates a virtual machine on your Windows 7 desktop that you can use to run legacy applications.  It can be downloaded here.  Make sure you remember the password you create, because even if you check the box for automatic log in, you'll need it in a few steps.

Once I got this up and running (it's pretty buggy), I copied my MS-DOS program onto the virtual XP machine and tried to run it.  Guess what? Same error!

The video device failed to initialize for fullscreen mode. Choose 'Close' to terminate the application.

This seemed bizarre to me, so I changed the only readily-available setting for the VM:  I clicked on Tools --> Disable Integration Features.  After doing this, the program ran perfectly!

What a pain, just for some old DOS program, huh?

32/64-bit NTPRINT.INF issues

When I tried to add 32-bit drivers to our 64-bit Windows Server 2008 print server (for sharing purposes), the driver installation process kept asking for an x86 (32-bit) NTPRINT.INF file.  I'm guessing it doesn't have this because it is a 64-bit server, but when I try to point it to the NTPRINT.INF file on a 32-bit server it still doesn't like it.

The fastest solution is as follows:

• Log in as a print server Administrator on a 32-bit server (a 32-bit client machine might work also). 
• Browse to your print server's UNC path (\\printserver).
• Open the Printers and Faxes share.
• Right click on the printer you wish to add 32-bit drivers to and click Properties.
• From this point, add the drivers just as you normally would.  It shouldn't give you any NTPRINT.INF issues!

Exchange 2003 Version Store Crash!

As I walked in the door this morning, our Exchange 2003 mail server greeted me with a massive failure.  The server's informaiton store service was frozen, and users were getting all sorts of bizarre errors when launching Outlook or trying to connect via webmail.

On the mail server, we noticed the following event log entries shortly before the store crashed:


Event ID 218 (Symantec Mail Security for Exchange):

The attachment "--FILENAME--" located in message with subject "--REMOVED--", located in --USERNAME--/Inbox has violated the following policy settings:

Scan: Auto-Protect
Rule: Unscannable File Rule
The following actions were taken on it:
The attachment "--FILENAME--" was Quarantined for the following reason(s):
Scan Engine Error. The maximum cumulative file size within a compressed file has been exceeded

Event ID 218 (Symantec Mail Security for Exchange):

The attachment "--FILENAME--" located in message with subject "--SUBJECT--", located in --USERNAME--/Inbox has violated the following policy settings:

Scan: Auto-Protect
Rule: Unscannable File Rule
The following actions were taken on it:
The attachment "--FILENAME--" was Quarantined for the following reason(s):
Timeout occurred while scanning this item

Event ID 9791 (MSExchangeIS Mailbox Store / Background Cleanup):

Cleanup of the DeliveredTo table for database 'First Storage Group\Mailbox Store (--SERVERNAME--)' was pre-empted because the database engine's version store was growing too large. 0 entries were purged.
 
The store finally crashed when this event log error was recorded:
 
Event ID 623 (ESE / Transaction Manager):
Information Store (10180) First Storage Group: The version store for this instance (0) has reached its maximum size of 155Mb. It is likely that a long-running transaction is preventing cleanup of the version store and causing it to build up in size. Updates will be rejected until the long-running transaction has been completely committed or rolled back.

Possible long-running transaction:
SessionId: 0x7FD31E20
Session-context: 0x00000000
Session-context ThreadId: 0x00000EB0
Cleanup: 1

Here is what happened:

One of our users was sent a few 200MB-ish

Rebooting the server fixed the problem temporarily, but within a few minutes we began receiving the same event log errors (minus the ESE error) again, leading me to believe that the store was on its way to another spectacular crash.

In order to remove these messages that were causing us so much grief, I used a utility called MFCMapi.exe.  It is extremely useful for multiple back-end Exchange tasks, and can be downloaded here.  You have to set up an Outlook profile for an Exchange Administrator on your PC, then launch MFCMapi.exe:

• Click Session --> Logon only (Does not display stores).
• Select the profile of the Exchange Administrator and click OK.  Nothing will change on the screen; that's okay.
• Click MDB --> Get Mailbox Table...
• Type in the username/password of the Exchange Administrator you created the outlook profile for, if required.
• Leave the defaults in the next window and click OK.
• This will pull up a list of all the mailboxes on the server you set up the Outlook profile to connect to.
• Find and double-click the problem user (identified in my case by the Symantec Mail Security for Exchange event log errors).
• Expand Root Container --> Top of Information Store --> Double-click the folder that contains the problem email.
• You can sort the contents in the window that appears by size.  This is the easiest way to find large emails.  Once I found the 200Mb email that was causing the problem I right clicked it and selected Delete Attachments...
• Leave the pop-up blank to delete all attachments in the selected email.

After taking the steps listed above I didn't have any further issues.  I am still not sure how a 200Mb email ended up in our mail store, however...  Let me know if you have any ideas!