WebGate and the IE / CSS Flicker Bug

Gettng quite specific here - but if you have this problem, you'll appreciate the info...
There is an annoying behavior that can occur in Internet Explorer. It is referred to as the 'IE CSS Flicker Bug'. This bug manifests as repeated requests being issued for the exact same resource (like a gif image). The result is a very slow or, sometimes, unusably slow user interface as the browser bogs down under (sometimes hundreds) of identical requests. For whatever reason, the IE fails to inspect its own cache for image resources that are defined in a CSS declaration and always issues a new request for each instance of the same resource.
Of course, there is a resolution to the issue. This involves tuning some specific settings on the webserver that serves image files.

IIS Webserver Configuration to Correct IE Flicker

The trick is to specifically set some content expiration and cache control headers that trigger IE to look into its own cache before issuing a new request.
On the directory that contains the resources in question configure: (the following is IIS specific but you can extend the same concept to Apache, etc.)

• Enable Content Expiration
• Expire after 30 days
• Cache-Control: max-age=2592000;

! note: there is a typo in the screen shot where the dash character is missing from CacheControl. Should read Cache-Control.

Where the WebGate Fits In

That's all the info you can find about this issue on the web. But if the UI in question is protected by a WebGate, you might apply the above mentioned measures only to find no improvement in the browser behavior. By default, the COREid WebGate is configured to apply two HTTP headers to each response it handles. Out of the box, the value for both CachePragmaHeader and CacheControlHeader is no-cache. Because the WebGate is always the last component to apply headers, it effectively overrides the headers supplied by the web server.
In the WebGateStatic.lst file, change both the CachePragmaHeader and CacheControlHeader to 'public'. (Yes, this may have other consequences so test carefully.)

That should be all that is needed to end any issues with the IE CSS Flicker bug if it, one day, plagues you.

COREid services start before LDAP

In COREid deployments where the Access and/or Identity services are installed on the same box as the LDAP server, the COREid service(s) sometimes start faster than LDAP. This behavior will cause errors in the oblogs (ie Directory is unreachable, down, or incorrect connection parameters were specified) after a reboot, and will cause the service(s) to stop (when the LDAP in question contains the COREid configuration container).

To avoid this problem on Windows platform installations, dependencies between the services can be created:

1. Locate Registry Entry for LDAP Service and note name: (ie HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ADAM_*)
2. Locate Registry Entry for COREid Service(s): (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ObAAAServer-*, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ObOISServer-*)
3. In each, add a Multi-String Value called DependOnService with a value that is the name of the LDAP service (ie ADAM_*)
4. Reboot

After rebooting, the COREid service(s) will wait until the LDAP service has sucessfully started before starting.
Additional Notes:

• This type of configuration is only useful when the COREid service(s) are configured to ONLY connect to one LDAP instance (no failover or redundancy) that is located on the same server (ie development/test environments)
• Multiple LDAP service names can be added to these registry keys (if using seperate LDAP directories for user, policy, or config containers)
• This dependency relationship will also cause COREid service(s) to restart/stop when restarting/stoping LDAP service