Archive for September, 2008
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.
Submit your website and/or RSS feed to some top search engines:
- Google – Free Submission: http://www.google.com/addurl
- Yahoo – Free for Non-Priority Submission: https://siteexplorer.search.yahoo.com/submit
- Bing / Microsoft Live – Free Submission: http://search.msn.com/docs/submit.aspx
- Ask – Free Submission: Use the sitemap submission interface
- Open Directory Project – Free Submission and often spidered by other engines: http://www.dmoz.org/add.html
You can also add your sitemaps and/or feeds here:
- Google – Webmaster Tools for Sitemaps: https://www.google.com/webmasters/
- Yahoo – Feeds and Sitemaps via the Feeds Button: https://siteexplorer.search.yahoo.com
- Bing / Microsoft Live – http://webmaster.live.com/webmaster/ping.aspx?siteMap=http://yourdomain.com/yoursitemap.xml. For example, http://webmaster.live.com/webmaster/ping.aspx?siteMap=http://www.grantburton.com/sitemap.xml. Check the crawl status through the Bing / Microsoft Live Webmaster Site: http://www.bing.com/webmaster .
- MoreOver: http://api.moreover.com/ping?u=http://yourdomain.com/yoursitemap.xml. Make sure to change the URL to match your site, for example http://api.moreover.com/ping?u=http://www.grantburton.com/sitemap.xml.
- ASK – Sitemaps: http://submissions.ask.com/ping?sitemap=http%3A//www.yourdomain.com/sitemap.xml. Make sure to change the URL to match your site, for example http://submissions.ask.com/ping?sitemap=http%3A//www.grantburton.com/sitemap.xml.
We will try to update this page whenever possible, but additions are greatly welcome!
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.
When opening a company file across a network on a machine running a QuickBooks 2008 Database Server, the user was unable to open the file in Multi-User Mode. The error was H202 – “You are trying to work with a company file that is located on another computer and this copy of QuickBooks cannot reach the server on that computer”.
After confirming read/write access to the network drive, confirming the appropriate firewall exceptions for the executables, deleting the *.ND files in the share, and then rescanning with the QuickBooks Database Server Manager to create new *.ND files, we still could not open the company file.
It turns out the mapped drive script uses the FQDN (eg, \\quickbooksDB.corp.companyname.com\qb$) to access the share. Once the script mapping was changed to just use the hostname (eg, \\quickbooksDB\qb$), the user could successfully out the company file.
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.
A client of mine recently contacted me with a number of Exchange related problems. Various company Executives were seeing duplicate and vanishing appointments in their Entourage Calendar. Most of the company Execs were on Macs using Entourage 2008, while their assistants were using Outlook 2003/2007 on Windows based PC’s will full delegation rights.
After examining the Exchange entries, it appears the duplicates were being created solely by the Entourage clients. Further examination of the Mac clients revealed that they also had the Sync Services Enabled for Entourage.
By disabling the Sync Services for Entourage, it eliminated duplications from the corrupted truth database. Unfortunately, some of the Execs wanted Entourage data to continue to sync with their .Mac accounts, despite the same information being available from any web browser via OWA. This required fixing the somewhat buggy Sync Service.
The Sync Service works as an intermediate between your various applications/devices and the data they contain. When an application like Entourage syncs with the Sync Service, the data is copied from Entourage to the truth database. At that point, other applications like iCal further synchronize the data with the truth database.
iCal <–> Truth DB <–> Entourage <–> Exchange
For an excellent article on sync’ing, check out the Entourage Help Blog and “Why does syncing play Gossip with my contacts?“.
To fix the issues my clients were experiencing, I had to purge the corrupt truth database and re-sync using Entourage as the master database. If you want to do something similar, follow these steps:
- Back up all iCal, Address Book, and Entourage Data. If you fail to do this and make a mistake, you will lose data.
- Turn OFF the Sync Services for Entourage in the Entourage Preferences on ALL clients that connect to the Exchange server.
- Remove the duplicate items in Entourage using these tools.
- Delete duplicate iCal appointments using John Maisey’s iCal Dupe Deleter.
- WARNING: The remaining steps will delete data – Make sure you have a valid BACK UP before proceeding.
- Quit all Microsoft Office applications except Entourage
- In the Entourage menu select “Turn Off Office Reminders”
- Quit Entourage
- Start the “Activity Monitor”, select “database daemon”, and choose “Quit Process” from the Processes Menu (perform a Normal Quit, not a Force Quit)
- Quit iCal, Address Book, Safari, and any other applications that sync with a .Mac account
- Use Activity Monitor to quit the Sync Services
- Delete the contents of ~/Library/Application Support/SyncServices/
- Since Entourage is going to be the primary source of data, delete the iCal and Address Book data files:
- Delete ~/Application Support/iCal/*~/Application Support/AddressBook/*
- Delete ~/Library/Caches/com.apple.iCal/*
- Delete ~/Library/Caches/com.apple.AddressBook/*
- Open the .Mac applet via the System Preferences and Verify .Mac syncing is enabled
- Restart all applications that sync with .Mac (ie, iCal, Address Book, Safari, etc)
- Turn on the Sync Services in the Entourage Preferences
- When prompted with the “Replace, Replace, Merge” dialogue, since we select Entourage to be the primary source of data, make sure to choose “Replace Sync Services items with Entourage items”.
From what I have experienced, synchronizing an Exchange linked Entourage client with a .Mac is frequently problematic and I do not recommend it at the time this article was written. If you must use this functionality, make sure to always make additions/changes/deletions from one machine and with a single application. You should then give some time for synchronization to occur before using another machine/app. As you can imagine, this can be an issue for users with delegates constantly changing Exchange data from another machine!
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.