Adobe ARM - Time elapsed is less than time limit - returning 0

Issue

The AdobeARM.log file contains similar entries:

[YYYY-MM-DD HH:MM:SS] IsTimeElapsed...
[YYYY-MM-DD HH:MM:SS] Minutes elapsed: MMM
[YYYY-MM-DD HH:MM:SS] Time elapsed is less than time limit - returning 0

Cause

By default, the Updater performs an update check every 3 days. The Updater adds the update check interval (3 days) to the value of tLasT_Acrobat. If the current date/time is less than this value, the Updater will exit without checking for updates and log the message.

Solution

Removing the tLastT_Acrobat entry will allow the Updater to perform the check.

Run the following via a Command Prompt.

REG DELETE "HKEY_USERS\.DEFAULT\Software\Adobe\Adobe ARM\1.0\ARM" /V "tLastT_Acrobat" /F

UAC, Administrators and Logon Scripts...

Logon script implementations prior to User Account Control (UAC) were fairly simple. Apply a logon script to user and the script did what it was supposed to. Post-UAC is a much different experience. There are things to take into account that, hopefully, this post will help explain.

Logon scripts can be applied to user accounts using

• The Active Directory Logon script defined in the user account properties
  NOTE: Only one can be specified. Therefore, it would need to call others.

•  A GPO Logon script

When a user is not part of the local Administrators group, scripts execute under the standard user access token. But when the user is part of the local Administrators group, scripts execute differently.

In the following scenarios, two logon scripts were applied at each login. Either both batch (CMD) or both VBScript (VBS).

Red = Bad, Yellow = OK, Green = Good

In conclusion, we found that using the Active Directory Logon script defined in the user account properties in conjunction with a VBScript file provided the most reliable results. This provided accurate drive mappings for the standard user account and no drive mapping for the administrative user account (or elevation). Conversely, the use of a batch file did allow accurate drive mappings for the standard user account, it also provided unavailable drive mappings to the administrative user account.

NOTE: This post does not apply to mapping drives using Group Policy Preferences.

Oracle Java Deployment Rule Set still broken

When Oracle began building in stronger security measures in their Java products in December 2012 with version 7 Update 10, IT departments discovered that the product could no longer work correctly. End users found that the product could no longer access Java applets or applications without error messages being presented. Enterprises found that the additional security did not include measures to bypass it, even for their own internally owned sites.

In September of 2013, Oracle released Deployment Rule Set (DRS) with Java 7 Update 40. DRS introduced the use of an XML file that allowed for defining a site and whether it was allowed to run. An extension to allowing the site to run, the XML could also define which version of Java to run the site with.

These versions do not support the feature to use a specific version of Java for a specified site.

Java 7 Releases	Release Date
Java 7 Update 60 Limited Update	May 28, 2014
Java 7 Update 55 CPU	April 15, 2014
Java 7 Update 51 CPU	January 14, 2014
Java 7 Update 45 CPU	October 15, 2013
Java 7 Update 40 Limited Update	September 10, 2013

If you've been stressing-out attempting to get this functionality working, waiting until a version that works is released would alleviate that stress.

REFERENCE

Deployment Rule Set
http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/deployment_rules.html

The cache disk on a Citrix PVS target fills and a server that is attached to it crashes.

Symptoms

Above normal CPU utilitization by the DAgentUI.exe process(es).
The per-user log, DAgentUI{USERNAME}{PID}.log, contains the following entries, repeatedly:

[MM/DD/YYYY hh:mm:s.ms TID #] DAgentProxy.cpp:518 CDAgentProxy::WaitForDAgentService() Waiting 15000 ms for DAgent service
[MM/DD/YYYY hh:mm:s.ms TID #] DAgentProxy.cpp:546 CDAgentProxy::WaitForDAgentService() Wait returned - -1
[MM/DD/YYYY hh:mm:s.ms TID #] DAgentProxy.cpp:362 CDAgentProxy::WaitForDAgentData() entered
[MM/DD/YYYY hh:mm:s.ms TID #] HideTrayIconThread.cpp:37 CHideTrayIconThread::HideClientTrayIcon() entered
[MM/DD/YYYY hh:mm:s.ms TID #] HideTrayIconThread.cpp:51 Destroying tray icon

Cause

The Altiris Deployment Agent service is not running or has been disabled. This causes the per-user log to fill with events and subsequently fill the cache disk. 

Solution

If the service MUST be disabled, delete the DAgentUI registry value in the registry that starts the per-user process (DAgentUI.exe).

Otherwise, start the Altiris Deployment Agent service.