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:
[sourcecode]subst NewDriveLetter: JungleDiskDriveLetter:\[/sourcecode]
For example, if the JungleDisk drive letter is “J:\”, you will run the following command to access the share:
[sourcecode]subst k: j:\[/sourcecode]
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.
After a Windows 2003 Small Business Server failed to shutdown using APC’s PowerChute UPS software, it was having trouble querying and applying the group policy settings.
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1058
Description:
Windows cannot access the file gpt.ini for GPO CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=domain,DC=local. The file must be present at the location <\\Random_Domain_Name.local\sysvol\domain.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.i ni>
— And —
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1030
Description:
Windows cannot query for the list of Group Policy objects. Check the event log for possible messages previously logged by the policy engine that describes the reason for this.
Successful repair steps taken:
If this does not correct your issue, the following Microsoft Knowledge Base articles might help:
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:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
Policies\system\LocalAccountTokenFilterPolicy
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”:
%SYSTEMROOT%\Temp
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:
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:
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:
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:
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:
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:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\
CurrentVersion\Uninstall\ENTERPRISER
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:
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.
SecurityFocus News SecurityFocus Vulnerabilities Security Headlines TechNet Security Headlines