"This webpage has a redirect loop."

Using Google Chrome.

Gibson Research Corporation Cookie Forensics states to disable 3rd party cookies.

After disabling 3rd party cookies, entering credentials into accounts.google.com reloads the page allowing for the credentials to be entered again. Odd, but after this second time, the page loads correctly.

Attempts to correct #1

ACTION

In Settings, Show advanced settings..., Content Settings (under Privacy), Manage Exceptions (under Cookies); Add the following:

Hostname pattern: [*.]accounts.google.com
Behavior: Allow

RESULT

The address bar began a noticeable loop, finally ending with a message stating "This webpage has a redirect loop."
Attempts to correct #2

ACTION

In Settings, Show advanced settings..., Content Settings (under Privacy), Manage Exceptions (under Cookies); Modify the following:

Hostname pattern (Existing): [*.]accounts.google.com
Hostname pattern (Change to): [*.]google.com
Behavior: Allow

RESULT

The web page loaded successfully with only one login attempt.

CONCLUSION

When 3rd party cookies are disabled, websites may fail to load. In the case of Google, 3rd party cookies are used (and my guess, heavily) throughout their sites. Because of this, when 3rd party cookies are disable, their pages do not load. Initially, the issue appears to be with just the accounts.google.com site. When the accounts.google.com sites are allowed and the page starts looping, it happens so fast that the other google.com sites are unknown. Adding all google.com sites resolves the issue.

MORE INFORMATION

After making these changes, the page will load but additional blocking may show in the address bar. This could be due to Google's acquisition of YouTube. To correct for this, add the following:

Hostname pattern: [*.]youtube.com
Behavior: Allow

Logitech TV Cam HD (PN 960-000921)

After spending some time at Best Buy today, I thought I would create this page so that others would know the specifications for the Logitech TV Cam HD.

Skype Options

Calling

• Skype-to-Skype
• Phones and mobiles¹
• Conference Calls
• Voicemail (aka Voice Messaging)
• Caller ID
• Call Forwarding
• Call Transfer

Video

• Video calling
• Group video calling
• Screen Sharing

Messaging

• Instant Messaging
• Send Files
• Text Messaging
• Facebook News Feed
• SMS

Other

• Skype WiFi
• Online Number
• Skype To Go

Logitech Device Options

• Skype app built-in *
• Skype Certified
• HDMI connection to TV
• Widescreen HD 720p video **
• Wi-Fi (802.11 g/n) or Ethernet connection
• Built-in ringer (rings if TV is on or off)
• Carl Zeiss optics
• Logitech Fluid Crystal™ Technology
• Digital zoom, pan & tilt
• 4 noise cancelling microphones
• No computer required
• Width: 9-19/32"
• Depth: 2-51/64"
• Height: 2-5/64"

¹ Requires Skype Credit or a subscription.

* The version of Skype included does not support group calling.
** 1 1.2 Mbps upload/download for 720p video calling.

Windows 64-bit uses MSHTA.EXE 32-bit

By default, Windows 2008 R2 uses the 32-bit version of MSHTA.EXE even if the parent process is 64-bit, such as double-clicking an HTA from the Explorer process. This is due to the htafile association pointing to the 32-bit version.

While it seems that this should be corrected by updating the registry with the 64-bit path, there are sites on the Internet the state this might not be a good idea; though no reason was given. A quick guess is that the server-based HTA's used for server configuration may break.

An issue that was encountered due to this configuration is the calling of 32-bit programs when only the 64-bit version actually works.

For example, calling the NBTSTAT.EXE command from a 32-bit Command Prompt will result in the following error:

'nbtstat' is not recognized as an internal or external command, operable program or batch file.

The same error is encountered when using WScript.Shell.Exec to call NBTSTAT.EXE from a 32-bit MSHTA.EXE on a 64-bit operating system.

As a workaround, call the 64-bit/32-bit version directly by using a CMD or BAT file that uses a similar command (this command will call the 32-bit version on a 32-bit OS and the 64-bit version on a 64-bit OS):

START %windir%\system32\mshta.exe "<PathToHTA>"

Package Servers are not able to download Symantec Deployment Solution 7.1 packages

Issue

Package servers show a number of invalid packages when the packages are valid.

Cause

The manually defined Package Destination Location (\\%COMPUTERNAME%\Deployment\...), does not exist because the Task Server role has not been assigned to the Package Server.

NOTE: The manually defined Package Destination Location was set by Symantec.

Workarounds

• Assign the Task Server role to the Package Server. (Preferred)
• Remove the manually defined Package Destination Location. This may cause issues with Symantec Deployment Solution, but will allow the package to download to the Package Server.
• Create the share on the Package Server using a similar command line:

More Information

A review of the Symantec Management Platform, Site Servers page shows that one or more Package Servers have invalid packages.

A review of the Symantec Management Agent, Package Server tab shows that the packages are related to Symantec Deployment Solution.

A review of the package on the Symantec Management Platform server shows that the package is set to download to All Package Servers, but to a manually defined Package Destination Location.

The manually defined Package Destination Location is associated with Task Server.

Where Symantec Management Platform Will Fail Your Company

The short...

Fixes for versions of Symantec Management Platform are not provided; Instead their solution is either to uninstall and re-install the current version or upgrade to a newer version.

The not-so short...

Symantec (formerly Altiris) produces a software product called Symantec Management Platform (formerly Altiris Notification Server). This product has been around for many years and has many excellent features such as inventory, reporting and software delivery (including patches). The use of this product in any environment is a valuable asset.

Once this product is installed and collecting data, the potential for problems increases. This may be exampled by having a slow web-based console or the inability to manage data within pages in the console (such as workstations, servers or patches). In my experience, this is mostly due to poor management of the data entering and leaving their SQL database.

When contacting Symantec support, the most common answer provided is either to uninstall and reinstall the product (if an upgrade is not available) or upgrade to the latest version (if an upgrade is available). The problem with this is that both options have the potential to, and have been known to, revert user-specified options back to default.

To have agents rolling out or policy schedules change after an uninstall/re-install is frustrating to say the least. And this is only for items a customer can see changed.
Upgrading to a newer version is more involved than fixing the current version. Every upgrade requires a push of new agents, policies, etc. This requires time to plan and implement which is not realistic when the customer only wants to fix a current version issue.

An example...

A customer calls Symantec support after having Symantec Management Platform 7.1 SP1 installed and running for over 9 months. They are complaining of slowness in the console and are unable to download patch data.

After hours of troubleshooting the issue, the Symantec support technician suggests repairing the current installation.

The repair fails with Symantec Installation Manager stating it cannot repair Symantec Management Platform 7.1 SP1 because it could not install Symantec Management Platform 7.1 SP2.

What started as a repair of the current version progressed into an upgrade without understanding or notification from Symantec support. What state would the environment been in if it had succeeded?!

Conclusion

Symantec support is a great resource for discovering what is causing issues with the product. The problem arises when support is unable to determine the cause. It seems they default to the standard "Reboot, rinse and repeat" method; This is great for simple issues, but this product is anything but simple and requires more attention to detail.

The idea that any vendor considers either an uninstall and re-install of the current version or upgrade to a newer version as a way to fix a version is unacceptable.

A good company should want to partner with the customer to fix the issue; Not just because the customer requires the product to be working, but also because the company should want the same for all of their customers. They would be able to create a fix that could be provided to other customers experiencing the same issue. And possibly, if necessary, include the same fix in the newer version.

Removing Items from Apple Software Update

A challenge of Apple Software Update is that it attempts to install Updates and New Software that may not wanted by the end user or company. The following are instructions on a way to remove items from the list.

This article applies to Apple Software Update 2.1.3 for Windows, but may apply to other versions.

When Apple Software Update is executed, a window similar to the one below is shown.

Ignoring Update Manually

1. Open Apple Software Update
2. Select the Update or New Software item(s)
3. Select the Tools menu item
4. Select Ignore Selected Updates

Ignoring Update via Automation

Ignoring updates can be implemented using different methods, such a Group Policy Preference or logon script. Visibility of items in the Updates and New Software lists above is controlled by entering update keys into a registry key in the current user registry hive. Update keys for an Update or New Software can be found by viewing an Apple Software Update catalog.

Apple Software Update catalog for Mac URL
http://swscan.apple.com/content/catalogs/index.sucatalog

Apple Software Update catalog for Windows URL
http://swscan.apple.com/content/catalogs/others/index-windows-1.sucatalog

NOTE: These links only contain current update keys.

To export a full list of update keys using PowerShell (to block all updates) (Windows)

1. Download the sucatalog
2. In PowerShell, run the following:
   
   NOTE: The list of update keys will be in the clipboard.

This is what the Safari 5 item looks like in the index-windows-1.sucatalog; showing update key (041-3083) and MSI (Safari.msi).

These update keys can be entered into the following registry key:

Key: HKEY_CURRENT_USER\SOFTWARE\Apple Inc.\Apple Software Update
ValueType: REG_MULTI_SZ
Value: Update_Ignore_List
Data: <AppleSoftwareUpdateKeys>

NOTE: This key cannot be transposed to a per-system entry in HKEY_LOCAL_MACHINE.

Update keys can be entered manually into the registry or via a form of automation, such as the following:

Once the registry value is present and Apple Software Update is executed, a window similar to the one below is shown: