Posted by William Diaz on October 28, 2013
I’ve been taking Internet Explorer 11 for a test drive recently and started to notice an odd occurrence. Upon initially opening IE 11 and typing www.google.com into the address bar, I am unable to get to the page, instead getting the generic : “This page can’t be displayed…”
A quick refresh, however, had no problems taking me to the page afterwards. Closing IE (and making sure all iexplore.exe processes are closed via the Task Manager) and typing the same URL again would reproduce the problem roughly 8 out of 10 times. A quick look with Network Monitor should that connection was, in fact, successful:
Looking at one of the frames in the network capture showed the presence of an additional HTTP protocol I wasn’t familiar with in Internet Explorer, SPDY/3:
I remember seeing it in the Advanced tab of the Internet Explorer settings:
Unchecking this setting resolved the issue. I am not sure why this is happening. SPDY/3 is a relatively new open protocol introduced by Google and being adapted by IE. More about it can be read here: http://en.wikipedia.org/wiki/SPDY & http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3. In short, it makes the browser speedier by reducing web page load times.
Seems to be reproducible only behind a proxy, TMG in our case.
Posted in Uncategorized | Tagged: Internet Explorer, Networking | 9 Comments »
Posted by William Diaz on October 23, 2013
After moving to Java 7 several months ago, this issue started plaguing us. During normal troubleshooting of Java applet-website issues techs would try to uninstall our custom Java 7 package, only to encounter: “There was a problem starting C:\Program Files (x86)\Java\jre7\bin\\installer.dll. The specified module could not be found.”
Up until recently, the fix was to run the Microsoft FixIt Utility to Fix problems with Programs that can’t be installed or uninstalled. Afterwards, we would then need to remove the stubborn registry entries that left the Program and Features application list populated with the now removed application by running the uninstall again. With the recent expiration of Java 7 update 25 and confusion from tier 1 support, there were several updates being done to the new JRE. In order to maintain a consistent software environment, I asked to have those updated JREs put back to 7.25. This also required uninstalling 7.25 on so many workstations that my head was left spinning because the process had to be done manually and I was the “go-to” person for the Java crisis. More importantly, at some point we would need to eventually update to a new JRE and likely want to remove the old one but not have a way to automatically uninstall the previous client with the uninstall broken.
After some web research, I found that the issue was with one of the custom actions in the Java msi, UninstallJRE:
This should be changed to:
Thanks to Keith Jones. Found this gem here: http://lists.wpkg.org/pipermail/wpkg-users/2013-May/009394.html.
Posted in Uncategorized | Tagged: Java | 3 Comments »
Posted by William Diaz on October 21, 2013
So, last week with the expiration of Java 7 Update 25, Java LiveConnect stopped working on several web sites that our users frequent, forcing them to change the default Java security setting from High to Medium. For arguments sake you could update to Java 7 Update 45 and go back to using the High security setting. But then I saw some additional text on one of the common Java 7 security dialogs: “This application will be blocked in a future Java security update because the JAR file manifest does not contain the Permissions attribute…”
Assuming the applet is not updated by the next JRE expiration, user’s would then have to lower Java security again.
Posted in Uncategorized | Tagged: Java | Leave a Comment »
Posted by William Diaz on October 17, 2013
So Java just released JRE 7 Update 45. This is apparent when someone goes to run a Java applet and encounters the following prompt:”Your Java version is out of date…”
For the average home user, this is not a big deal. But in a corporate environment headaches ensue. Why? Because some users will blindly click on the Update button and be redirected to the Java download page for the latest release. The first problem is that our users are not going to have the administrative privileges to update their Java client. But the real problem is that once a user has done this, they will be redirected to the Java download page each and every time they need to run a Java applet. So the question was, how do we get the prompt back so the user can select the appropriate Later option and Do not ask again until the next update is available?
For starters, the property that controls this setting is located in a file called deployment.properties in %userprofile\AppData\LocalLow\Sun\Java\Deployment named deployment.expiration.decision.10.25.2=update:
Posted in Troubleshooting | Tagged: Java | Leave a Comment »
Posted by William Diaz on October 4, 2013
An interesting little quickie. After moving to mandatory profiles in a Citrix environment, a particular ActiveX web application would no longer allow logins. There was no error message of any kind and it continued to work in another Citrix environment without mandatory profiles. I fired up Process Monitor and ran a little trace of Internet Explorer to capture everything that happened after I clicked login. Nothing interesting really stood out but there might be some hope in an activity log activity I saw occurring with the application:
Opening the log showed:
[W] 2013/10/03 22:46:00 PM fyiCryptAcquireContext(): CryptAcquireContext() failure while trying to acquire the crypto context/container (GetLastError() -2146893788, (The profile for the user is a temporary profile.)) Thu Oct 03 22:46:00 2013
[I] 2013/10/03 22:46:00 PM fyiCryptAcquireContext(): CryptAcquireContext() failed while initializing the crypto context (GetLastError()=-2146893788 (The profile for the user is a temporary profile.)), I will try and re/generate a brand new container Thu Oct 03 22:46:00 2013
[E] 2013/10/03 22:46:00 PM fyiCryptAcquireContext(): CryptAcquireContext() failure, can’t acquire, nor create a new container (2) (GetLastError() -2146893788, (The profile for the user is a temporary profile.)) Thu Oct 03 22:46:00 2013
Some quick research pointed me to RSACryptoServiceProvider fails when used with mandatory profiles. In short:
RSACryptoServiceProvider calls CryptAcquireContext API (http://msdn2.microsoft.com/en-us/library/aa379886.aspx) behind the scenes to get a handle to a key container within a CSP (Cryptographic Service Provider). CryptAcquireContext will fail with NTE_TEMPORARY_PROFILE error when called from a mandatory profile.
Mandatory profiles are read-only user profiles. Since changes to the mandatory profile cannot be saved, PKI design doesn’t allow this operation, and CryptAcquireContext prevents this scenario by failing.
Posted in Troubleshooting Tools | Tagged: Process Monitor | Leave a Comment »
Posted by William Diaz on October 2, 2013
While browsing various reports for workstation compliancy, I noticed that several reports and/or updates failed to install on a large number of computers. Although we don’t expect complete 100% compliancy with thousands of workstation in our environment, there was some sort of mystery going on here because many of the updates that failed to install were along the same computers, i.e. they were not just random computers across the various reports. For example, below is a report for various updates that were missing from generally the same number of computers and computer names:
After some research in the CCM logs, I noticed a repetitive theme in the C:\Windows\SysWOW64\CCM\Logs\UpdatesDeployment.log: “Install not allow as another job is still in progress”:
Using the SCCM Client Center utility, we compared the time in the logs to the Advertisement > Execution History in the SCCM Client Center and saw nothing that was actually trying to install at that time. Out of ideas, I decided to delete root\CCM namespace (also accomplished with the SCCM Client Center utility) on a few of the problem workstations in the reports above. After a few minutes, I noticed the CCM Cache in C:\Windows\Syswow64\CCM\Cache was rebuilt, pulling several pending updates. The next step was to wait for the SCCM service windows to pass. The next day when I came in, I remotely checked the workstation Event Setup logs and saw that several (sometimes dozens) of various pending updates had successfully installed.
Knowing that we had a problem with the CCM namespace, I followed up with some more research. My digging around eventually led me to what might have been an update that was advertised to these computers but likely pulled before it could be deployed. Specifically, what I found was that each update gets an unique update ID. To the CCM agent, this property is known as the AssignmentID, which resides in the instance of the CCM_DeploymentTaskEx1 of the root\CCM\SoftwareUpdates\DeploymentAgent namespace. I went around to several workstation in the SCCM reports and ran wbemtest.exe and saw the same assignmentId(s) across all the computers in the reports:
Read the rest of this entry »
Posted in Troubleshooting, Troubleshooting Tools | Leave a Comment »