Fixed: Facebook update constantly downloading and google play not working afterwards.

Last week my mobile phone started to constantly download a Facebook update which was draining the battery due to the constant downloading attempts. Trying to stop the download, I somehow managed to disable the download manager – this did fix the problem but for some reason also stops the Google play store from working. Every time I opened Google Play the application would just disappear from the screen. There was no forced close error message.  This was a bit of a problem as I had removed the Facebook app from my phone trying to stop the download and then was unable to reinstall it as the store would not open.

To fix this issue, Open Settings, Application Manager, scroll to All applications and then scroll down to the bottom of the screen. It is necessary to scroll all the way down as the disabled applications are at the bottom of the alphabetical list. Click on Downloads and then enable the application.

The app store will then start working and hopefully you won’t get the facebook update pushed down to your phone (I didn’t at least)

Fixed: DigitalPersona fingerprint reader with roaming profiles not saving passwords

The new laptop has a fingerprint reader included and comes with DigitalPersona’s fingerprint software. At first glance, this looks like a useful piece of software but after trying to use it, I’ve found it very buggy and the support is non-existant.  DigitalPersona offer no support for the product and refer  you to the OEM partner, in my case Dell, who have nothing in their knowledge base about this product either.

My problem was to do with our roaming profile. After receiving the laptop last night I synched (or so I thought) to the domain, took the machine home and logged in. Windows7 decides that it can’t load my profile and uses the temporary saved copy – all well and good for now, my desktop background, images, shortcuts etc all exist.  However every time I go to add a new website in DigitalPersona, it seems to take the information but does not actually save it to the machine.  Suspecting roaming profiles, I created a local user, logged on as that user and registered my fingers. Note that if you do this, when you use the Windows Login Screen and your finger to login, the pc automatically logs you in without asking which user you want to use. I’m not sure how it determines which user to use, but in my case it used my local user (which was also the most recently created user).

After logging on as the local user I was then able to launch Internet Explorer (9), log into gmail, facebook and this blog and register my usernames and passwords and DigitalPersona kept the information. At this point I also used the option to download and install updates to the software – the most recent version that is now running on the pc is 5.30.252a. Note to get to the updates, click on the plus sign by central management and then the update tab appears.

I then logged off the machine and logged back as my domain account. Tried to use DigitalPersona and yet again the software refused to take my passwords.  I opened explorer up, browsed to %appdata% and sure enough – there was no DigitalPersona directory.  I then browsed to c:\users\localusername\appdata\local and checked out the DigitalPersona directory. This contains an OTS directory and then a _dp_ots_tmp and DPIconCache directory. The tmp directory was empty and the DPIconCache directory contained an icon for the sites I’d saved the password to. I copied the DigitalPersona directroy from the localusers\appdata\local directory to my own %appdata% directory and magically was able to start saving passwords in IE9.

Unfortunately I’ve yet to get the program to work with Firefox or Keepass – the program is unable to detect Firefox or Keepass having a login window.

If anyone has a better (preferably free) password manager that works with IE, Firefox, Chrome and Keepass (last is optional) then please let me know.

Fixed – wifi not resolving dns on laptop with Windows7

I had a strange case the other day at work when all of a sudden my laptop would fail to resolve dns queries for my wireless connection only – my wired card was not affected. Changing dns entries to another server did not fix the issue. Eventually I tried disabling the Microsoft Virtual Wifi Miniport Adapter (from device manager) and immediately I was able to resolve dns again. Once I discovered this fix I remembered something similar with this adapter. Looking back through my previous notes we had an issue with Shrewsoft’s vpn software – with the Microsoft Virtual Wifi Miniport Adapter enabled we were unable to get a vpn session working to a Cisco client.
So far, disabling this adapter does not seem to have caused any issues – apparently it’s purpose is to allow you to connect to more than one wireless connection at the same time – an unlikely requirement in most business situations.

Fixed – Right click option to scan files missing in Microsoft Security Essentials Beta

I’ve been doing a bit of work with the latest beta this morning and found that the option to right click on a folder or file and scan it was missing. According to the connect website, the “Item Scan with Microsoft Security Essentials is missing from right click menu because file shellext.dll is not registered in the OS (C:\Program Files\Microsoft Security Client\shellext.dll). To resolve this issue, open a command prompt with administrator permissions, type regsvr32 “C:\Program Files\Microsoft Security Client\shellext.dll” and press ENTER.”
Sure enough this works. Thanks to 777Andrey777 for the solution on the connect website (login required).

The other issues that I have also encountered include the Windows Home Server connector monitor flags the fact that my av is out of date or turned off when the computer is rebooted – this lasts for about 20 to 30 seconds. The instructions to provide feedback are also missing on the connect website (which was not very helpful). However log files can be generated by running “mpcmdrun -getfiles” from the Microsoft Security Client\Antimalware directory within program files.

Could not open key UNKNOWN\Components – fixed

When attempting to install Exchange 2007 sp2 on a server I was getting the error message Could not open Key UNKNOWN\Components\ 32 hex numbers \ another 32 hex numbers (see below)
Not so useful error message when trying to install Exchange 2007 sp2.
This turned out to be occurring when the Rollup 9 package was being uninstalled. Checking into the registry and hklm \software \ microsoft \ windows \ CurrentVersion \ Installer \ UserData \ S-1-5-18 \ Components \ numbers \ numbers. Taking ownership of the parent registry key and then assigning my admin user full rights to the parent and cascading permissions would allow the procedure to continue a little bit further. Eventually after a couple of attempts I expanded the Components key in regedit using ctrl + and then used the arrow key to move all the way through, fixing permissions as required.  The lazy way would have been to set permissions at the Components Key but that may cause other problems I didn’t really want to deal with in the future.

I have no idea why the permissions were so screwed up but I really do not appreciate wasting 4 hours on a Saturday afternoon trying to fix the issue – it took a while to debug the initial errors and then more time to run the install, find out it kept causing errors with different registry locations and then navigate through the entire component tree.

The installation failed with: This patch package could not be opened – Fixed.

I have been trying to install the KB958481 patch for Microsoft Dot Net Framework 2 for many hours. Each time the installation would fail with “The installation failed with: This patch package could not be opened. Verify that the patch package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer Patch Package.”

Of course the patch file exists (I am installing it after all) and the patch file came from Microsoft so I would hope it’s valid.  Most of the suggestions seemed to resolve around removing the dotnet framework and reinstalling. All of which I had done in a variety of ways. First by uninstalling the software through add/remove programs and then through Aaron Stebner’s dotnet cleanup tool – neither of which solved the problem.

Eventually I stumbled across a tech posting (made after my initial problem started) in the Microsoft forums (first and second posting that mentioned installing the Microsoft Installer 4.5 redistributable component. After an initial reboot before installing, a reboot after installing, installing the .net patch and another reboot afterwards I was up and running and able to install the other .net patches too.

e000e020 with BackupExec backup job missed last night.

If you have the misfortune to have BackupExec at your client sites, you may have noticed your backups failed last night with “e000e020 – The job was scheduled to run, but the availability window closed before the job could start. There may not have been any destination devices available during the window, or the job may have been submitted to run when the window was closed”

Apparently this is due to Daylight Savings Time – the solution is to rerun the job or wait and see if it runs tonight – Thanks for a really helpful solution Symantec.

Symantec definitions slowly getting fixed.

Symantec have now released a patch that fixes the issue of definitions being dated 12/31/2009. However, the patch so far is only available for those running 11.03 or 11.05. For more details read the official statement on the Symantec forums or the Symantec Knowledgebase article . Most of our Endpoint Protection Servers were running 11.0.4 (as live update does not upgrade the server console component) so we have to upgrade to 11.0.5 first. This can be seen as a good thing as 11.0.4 has the nasty feature of filling up the hard drive of the server as Symantec downloads and keeps 3 copies of the av definitions every few minutes as it tries to download definitions dated in 2010 (and fails). So far, most of the Endpoint Protection Manager upgrades have been fairly simple with straightforward instructions – a 25 minute process after the files have been downloaded (including backing up the database) but we had one site that didn’t work and we had to reinstall every single Symantec Endpoint Protection client and server by hand. Not a lot of fun.

Symantec Definition date is stuck at December 31 2009

Most of our Symantec Endpoint Protection clients are alerting that the definition dates are old (we reduce the alert time to less than the default 30 days). These alerts are coming in through the desktop client and also through both of our monitoring systems. Apparently Symantec are aware of the issue (see “The date of the definitions in Symantec Endpoint Protection clients and Symantec Endpoint Protection Manager remain at Dec 31 2009”)  and their definitions cannot have a date in 2010. Therefore their work around is to push out new updates with a date of December 31st 2009 and they are just increasing the version number until engineering come up with a patch to fix the issue of not accepting dates in 2010.

I sure hope that their update plan works better than our most recent upgrade that meant we had to reinstall the client by hand at every desktop.  None of the upgrade processes would work.

Nothing happens when clicking on the start menu – fixed.

A while back we had a client that was migrating out of their existing domain and into a new SBS2008 installation. One of the things I learnt (too late) was to disable folder redirection before doing a migration otherwise clients will still point to the old server. Unfortunately I did not have access to the old server/domain but I had got a copy of the redirected folders and thankfully there was no real data on the server to be migrated from the redirected folders.

However to fix the redirected folders I had to use csccmd to remove references to the old server which was easy enough using “csccmd /unpin2:\\oldserver\share /recurse”. I then changed the registry entries in HKEY_CURRENT_USER \ Software \ Microsoft \ Windows \ CurrentVersion \ Explorer \ User Shell Folders to point to the new location.  This worked fine for every machine except one.  This particular machine had a very strange symptom in that when clicking on the Start/All Programs button the machine would pause for about 20 seconds and then nothing would happen (to the end user). Behind the scenes the Start Menu, Startup and Programs entries in the registry would get deleted. I tried to use ProcessMon from sysinternals to monitor the registry setting but I either got too much registry information to work out what was going on or nothing at all (depending on the filters I had applied).

Anyway, yesterday I stumbled across Ramesh’s site which mentioned running “regsvr32 /i shell32.dll”. I tried this, clicked on the All programs and nothing happened – again. I rebooted and the problem persisted. I then ran it again and was about to reboot the machine again when the user logged into the machine so I had to stop work (I was doing all this remotely using rdp). I logged into the machine this morning and checked the registry. Somehow the registry items were no longer blank but were repointing back to the original server. I reset them back to the new locations and now the All programs button works as designed. I think the trick was to run regsvr32 and then reboot before clicking on the All programs button. (Either that or reboot twice and then check the registry settings and correct them)