The Burton Tech Journal

Tag: gpo

Event ID 1030 and 1058 when querying Group Policy Objects

by on Nov.26, 2008, under Window Small Business Server 2003, Windows Server 2003

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 1058

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 1030

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:

  1. Download and install the Windows Server 2003 Service Pack 1 Support Tools.
  2. Once installed, open the command prompt and run: dfsutil /PurgeMupCache
  3. Then run: gpupdate /force
  4. Examine the Application Event log for Event ID 1704

If this does not correct your issue, the following Microsoft Knowledge Base articles might help:

  1. KB888943 – Event 1030 and event 1058 may be logged, and you may not be able to start the Group Policy snap-in on your Windows Small Business Server 2003 computer.
  2. KB842804 – A Windows Server 2003-based computer may stop responding when it is resumed from standby and events 1030 and 1058 are logged in the application log of a domain controller.
Leave a Comment :, , , , , , , , , , , , , more...

Check Windows Installer (MSI) Logs

by on Sep.21, 2008, under Microsoft Windows XP, Windows Application Deployment, Windows Vista

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.

Leave a Comment :, , , , , , , more...

Simulate a Windows Application Deployment Lifecycle

by on Sep.21, 2008, under Microsoft Windows XP, Windows Application Deployment, Windows Vista

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:

  1. MSIEXEC /i “\\path_to_msi” /qb
  2. The /i switch tells MSIEXEC to install or configure a product
  3. 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:

  1. MSIEXEC /x “\\path_to_msi” /qb
  2. 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:

  1. 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:

  1. 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:

  1. Examine the MSI logs on the client computer and make any adjustments necessary.
  2. Confirm Vista’s UAC is not blocking installation.
  3. 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.
Leave a Comment :, , , , , , , , , , , , , , , , more...

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!

Blogroll

A few highly recommended websites...