Some users may experience issues while trying to print web pages using Internet Explorer 7 and Internet Explorer 8 on Windows Vista and Windows 7. Rather than producing the web pages content in the print out, all that shows is the path to the temporary Internet file containing the content to be printed:
This appears to be a complication with Internet Explorer’s Protected Mode (see http://msdn.microsoft.com/en-us/library/bb250462%28VS.85%29.aspx). Even though the user has full permissions to modify the files and folders in the Temp directory, the Protected Mode prevents the “Low” directory from being created. You can fix the problem by running the following commands at the command prompt (cmd.exe):
- mkdir %userprofile%\AppData\Local\Temp\Low
- icacls %userprofile%\AppData\Local\Temp\Low /setintegritylevel low
Restart Internet Explorer and you should now be able to print successfully.
JungleDisk is a WebDAV file sharing service running on the Amazon Simple Storage Service (Amazon S3). It appears when users are using Office 2003 SP3 on a Vista Business SP1 based system, they may not be able to open Microsoft Word and Excel files. The users experience an error similar to:
Could not open ‘http://2667/somebucket/some file.doc’
The JungleDisk Support site (KBID#: 300065) indicates installing the Windows Software Update for Web Folders (KB907306) and rebooting will fix the problem. Unfortunately the reported fix does not appear to work for numerous users. Additionally, connecting to the JungleDisk “bucket” using the naive Windows WebDAV client does not allow saving due to the “read-only” bug.
We discovered the easiest way to work around the Vista/Office 2003 WebDAV limitations was to use a substitute drive. Once the JungleDisk client loads and you can access the JungleDisk network drives, the following command can be use to connect:
subst NewDriveLetter: JungleDiskDriveLetter:\
For example, if the JungleDisk drive letter is “J:\”, you will run the following command to access the share:
subst k: j:\
You should then be able to open files from and save files to the “k:” drive directly.
When your system reboots, you will need to run the subst command again. For our users, we have created a batch file that deletes the virtual drive (subst k: /d) then re-creates it (subst k: j:\). After the user’s system has completely loaded, they double-click on the batch files to create accessible virtual drives.
Incidentally, upgrading to Office 2007 on Vista or running Office 2003 from Windows XP does not appear to have any issues.
When connecting to a Vista machine from another machine that is not on the same domain, Vista will filter the token. You must disable Remote UAC in the Vista machine’s registry:
0 – build filtered token (Remote UAC enabled)
1 – build elevated token (Remote UAC disabled)
By setting the DWORD entry to 1, you will be able to access the administrative shares since the remote logon token will not be filtered.
Windows typically uses the following directory to store MSI logs with the filenames “Msi*.log”:
By examining the MSI logs most recently modified, you can often see installation issues, such as permission errors, registry problems, and dependancy errors:
dir /O-D /TW %SYSTEMROOT%\Temp\Msi*.log
If MSI logging is not enabled, you can enable it by editing the registry or via GPO. See KB223300 for details on how to enable logging.
If a domain test bed is not avaiable, either real or virtualized, it is best to use a single workstation to test an unproven MSI based package. Frequently the deployment process is hung up when the MSI performs a custom action that requires some form of user interaction. It is important to not only look for this behavior in new installations, but also MSI’s used to upgrade long functioning deployed applications, before introducing either to your GPO.
This is the recommended test procedure:
A) Perform an installation and look for dialogues that require user intervention:
- MSIEXEC /i “\\path_to_msi” /qb
- The /i switch tells MSIEXEC to install or configure a product
- The /qb switch tells MSIEXEC to use a basic UI
B) If the application does not install correctly, check the MSI log file for errors. Otherwise confirm the application is functioning correctly.
C) It is critical to test what happens during uninstallation of the application too. Any user interaction requirements could cause a failure when upgrading or removing your application later. Run the following command to observe the uninstall process:
- MSIEXEC /x “\\path_to_msi” /qb
- The /x switch tells MSIEXEC to uninstall the product
D) If the application installs and uninstalls without requiring user interaction, it will probably work fine deployed. To finalize a simulation, the application should be silently installed remotely using PSEXEC and the following commands:
- PSEXEC -u context\username -p password \\target_machine MSIEXEC.EXE /i “\\path_to_msi” /qn
E) Confirm the application functions correctly with an unprivileged user account. Check the MSI log on the target machine for errors if necessary.
F) Once again, test the uninstall process:
- PSEXEC -u context\username -p password \\target_machine MSIEXEC.EXE /x “\\path_to_msi” /qn
G) If the application appears to be working, you can proceed with assigning it to your GPO.
H) If application does not deploy, try the following:
- Examine the MSI logs on the client computer and make any adjustments necessary.
- Confirm Vista’s UAC is not blocking installation.
- Check http://www.appdeploy.com for valuable tips and tricks, particularly if you are deploying a popular commerical package. The site has some great resources on how to customize packages so they will install correctly.
Occassionally a workstation will show a mapped network drive as “Disconnected” in Windows Explorer. Double-clicking on the drive does not resume the connection and attempting to unmap the drive will give an error that “The network connection does not exist”.
Additionally you may see your login scripts not mapping other drives.
To correct the problem, download the User Profile Hive Cleanup Service from the Microsoft Downloads site and read the installation/usage instructions:
The following Office 2007 updates failed to install on Windows Vista Business with Error Code 57A:
KB950130, KB951338, KB951944, KB951596, KB954326, KB956080, KB951546
Examing the %systemroot%\Temp\MSI*.log files revealed that the admin account did not have access to the registry key:
Giving the administrators group and the system account ownership and Full Control of the registry key resolve the update issues.
The Windows Vista Check for System Update Readiness (CheckSUR) tool will try to fix certain Windows Update installation failures.
System resources, such as file data, registry data, and even in-memory data, can develop inconsistencies during the lifetime of the operating system. These inconsistencies may be caused by various hardware failures or by software issues. In some cases, these inconsistencies can affect the Windows Servicing Store, and they can cause a Windows Vista update to fail. When the update fails, it blocks the user from installing updates and service packs. CheckSUR addresses this issue.
When Windows Update detects inconsistencies that are related to system servicing in system files or in the registry, Windows Update offers CheckSUR as an available update package.
Note This Windows Update or Automatic Update package will only be offered if such inconsistencies have been detected on the system. CheckSUR should run automatically after it has been installed from Windows Update.
To manually install and run CheckSUR, follow these steps:
- Click Start , click All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.
- In the User Account Control dialog box, click Continue.
- Type reg add HKLM\COMPONENTS /v StoreCorruptTimeStamp /t REG_SZ /d “0” /f, and then press ENTER.
- Type reg delete
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\CheckSUR\, and then press ENTER.
- Download and then install CheckSUR from the Microsoft Download Center.
- As soon as the file has been successfully downloaded, double-click the file to install and run CheckSUR.
We recommend that you restart your computer after you run CheckSUR to make sure that any changes take effect. Additionally, you must try to reinstall any software updates that previously could not be installed. If CheckSUR detected and fixed the cause of the failures, these updates will now install successfully.
CheckSUR creates a log file that captures the issues, if any exist, that were found or fixed. The log file will be located at %WINDIR%\Logs\CBS\CheckSUR.log
CheckSUR is run by Windows Update after you install KB947821. Windows Update can take as long as 10 to 15 minutes to complete this scan. The time may be significantly longer on some computers. However, the Windows Update progress bar is not updated while this process is running, and it will not move. This means that the Windows Update progress bar may indicate that it is 0 percent complete, or 20 percent complete, and so on, for some time. This behavior is expected, and you should not cancel the update. If you cancel the update, some problems may not be identified, and this package may have to run again.