After Windows updates were applied last month, all the Vista computers at a client site were all showing a dialog box asking to update their print drivers with newer drivers from the Windows 2003 server. Unfortunately, clicking install doesn’t do anything. Bypassing the dialog box will also not work and prevents printing.
I first thought the updated print drivers weren’t Vista compatible. I followed this post by John Dickson to push Vista print drivers to a Windows 2003 server. You cannot install Vista print drivers on the Windows 2003 server directly and has to be pushed upstream from a Vista computer //blogs.technet.com/b/
askperf/archive/2008/09/19/installing-windows-vista-print-drivers-on-windows-server-2003.aspx. However, doing this did not fix printing or stop the prompts to update print drivers.
I decided to focus on the printer share on the Windows 2003 server instead. When I tried to print a test page from the server, it didn’t work. I was sure it was the printer driver on the server that was corrupt. To fix this, I added another printer object on the server using the same Ricoh 2404 print drivers. When prompted to use the same drivers or replace, I chose replace. After doing this, I was able to print a test page directly from the server.
I went back to the Vista workstations and sure enough, I was able to upgrade the print drivers and get rid of that annoying prompt to upgrade. I was also able to print a test page after that. I checked all the other Vista workstations and they are now able to print as expected.
I could have gone to all the computers and set them all up as direct IP printers insteaf of using the Windows 2003 Server as a print server but this is a lot of work. By focusing on the print server drivers, I was able fix everyone’s printing issue quickly.
Lesson learned: before anything, always do a print test page from the server console for that network printer.
I was helping Brian the other day with a problem he had running Remote Desktop to connect to the server so that he could use Business Vision. When you launch Remote Desktop MSTSC.exe, a dialog box comes up with the error message:
“Remote Desktop Connection has encountered a problem and needs to close”
I immediately thought of file corruption or virus infection. I searched for mstsc.exe and mstcax.dll to rename and replace them with another copy. However, as soon as I rename the extensions to .old the files revert to the original .exe and .dll extensions. Weird. I even tried deleting those two files but they keep reverting and keep getting restored back automatically. There appear to be some process that detects missing system files in \windows\system32 folder and restores them from saved copies. Correct me if I’m mistaken please.
I thought it was a virus and was about to install another antivirus software on his PC like MS Security Essentials but wanted to ask my good friend Google first. This is what I found //www.daniweb.com/hardware-and-software/microsoft-windows/windows-nt-2000-xp/threads/155652 and it worked for Brian. Apparently it is due to a windows update for Windows XP SP3. I followed Mikey’s suggestion in the forum, namely
1) Created a new folder “RDP” in \windows folder;
2) Copied “mstsc.exe” and “mstscax.dll” from “c:\Windows\
$NtServicePackUninstall$” to this folder;
3) Copied the “mstsc.exe.mui” and “mstscax.dll.mui” from “c:\Windows\System32\en-US” to “c:\Windows\RDP”;
4) Once it worked, I created and saved a connection bv.rdp file with server info, credentials, and startup parameters to “c:\Windows\RDP” folder;
5) Created an RDP shortcut “c:\Windows\RDP\mstsc.exe bv.rdp ” and saved that to his desktop.
This worked well for Brian and am passing it on in case you run into the same issue.
One of our clients has a Sonicwall firewall and is running into issues accessing hosted websites on the LAN when connected to the wireless LAN.
The wireless subnet which is off the WLAN interface on the firewall is getting blocked from accessing the webservers on the LAN interface. The webservers all have public IP addresses associated to them which are all pointed to the WAN interface of the firewall. A static NAT on the firewall is set to point publicly addressable IPs to the webservers on the LAN interface.
I believe the issue is related to NAT translations. Traffic from wireless WLAN interface has to go out to the WAN interface and then back in to the WAN interface to get finally handed over to the webservers on the LAN interface. I have tried changing the NAT rules so that the source for WLAN traffic is changed to the WAN interface but didn’t work.
Any suggestions in getting this to work?
In the meantime, I have set up a dummy authoritative DNS zones in Active Directory for the domains that the local webservers are hosted on. The intent is to point the A records to the local IP addresses of the webservers so that WLAN traffic goes directly to the LAN interface. This works and speeds up access to the websites for those on the WLAN and LAN. The main thing to remember is that these dummy DNS zones are authoritative in the LAN/WLAN so any changes with the external DNS provider will have to be manually added to this dummy zone.
If you need help with the setup, please comment here and I’ll follow up.
This is a followup post on issues we had with a client who upgraded to the 64-bit edition of Windows 7 Professional //aminsolutions.com/?p=160. This is the resolution for it.
The client has contacted all the vendors of his old software and we are just waiting for development work at their end to get their software ported to 64-bit. In the meantime, we followed some of the advice given to us by others to install MS Virtual PC and enable Windows XP mode. The procedure was fairly easy to follow online.
Download and install Windows XP Mode at //www.microsoft.com/windows/virtual-pc/download.aspx.
Step 1: Download Windows XP Mode
Step 2: Download Windows Virtual PC
Step 3: Update Windows XP Mode
After installing the two applications, go to MS Virtual PC program folder and run Windows XP Mode. This creates a virtual PC guest running Windows XP in 32-bit. You are prompted for a local administrator password for that virtual PC and I would suggest using the same password as your Windows 7 host. Also, enable autologons so that you aren’t prompted everytime. The virtual guest uses minimum amount of resources like 512MB of memory and will auto-connect to all the disk drives of the host Windows 7 PC. Having the disk drives auto-mapped allows for easy transfer of datafiles from host to guest. The CD/DVD drive was also mapped correctly and let us easily install the 16- and 32-bit applications on the guest simply by inserting the CD on the host.
The nice thing about Windows XP mode is the integration of these legacy applications in your Windows 7 host. After installation of these 16- and 32-bit applications on the virtual guest, they are added as entries in the MS Virtual PC applications programs group. They appear as if they were installed on your Windows 7 computer! How awesome is that?
I did run into three minor issues. 1) DOS programs that do not run through an installation script are not added automatically in the Virtual PC applications programs group. They are therefore run by launching the full MS Virtual PC console; 2) Brother 420CN printer on the Windows 7 host is not auto-created on the guest; and 3) the USB floppy drive on the host is not auto-mapped in the guest. I had to copy the floppy disk contents temporarily to a folder on the host and access those folders from the guest. There are fixes for these issues and I’ll post them here when I find out.
Other than that, I was excited to get it working for the client who is now ready to get rid of his old PC.