We had a weird issue this morning where the Archive options were missing in Outlook 2007. This is apparently a known issue with the kb2412171 December 14, 2010 outlook update which allegedly improves stability. It is hard to see how removing functionality, breaking send and receive and reducing performance when you switch folders comes under the category of improving stability and increasing performance.
Thankfully the solution is simple, just remove 2412171 from add/remove programs and everything should go back to normal.
Further details on the patch are also available which includes the known issues when installing 2412171.
Needless to say, we have unapproved this patch on our WSUS servers.
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.
I was getting the “‘gtLV’ is null or not an object” message when I replied to an email using our Microsoft Online Hosted Exchange email account. Ironically enough, the problem would always occur when I replied to a new email from a Microsoft support engineer. The email would go through but I would get the ” ‘gtLV’ is null or not an object” error message popup on the screen. If I replied to the email again the problem would not occur. A very similar message can be seen in the Microsoft Exchange Server forums where I also posted the provided solution.
After many emails to the very patient support tech at Microsoft (as I would reply and then send an email to let him know if the reply worked or not) we escalated the ticket and I got back the following resolution.
1. type regedit on command prompt or run
2. go to: HKCU\Software\Microsoft\Internet Explorer\Main
3. create TabProcGrowth (string or dword) and set the value to 0
This solution worked for me. From what I can see at the ie8blog this has the side effect of reducing the protectedmode protection and I think the browser tabs use the same process rather than running in seperate processes. This is a slight downside, but I doubt many users will care – they’re more than happy to have OWA working.
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.
Had an interesting troubleshooting session this afternoon on a Windows7 pc that was no longer having the screensaver kick in. After checking the screensaver settings were being deployed via group policy, disabling wake on lan and also preventing the network card from waking up the computer/allowing the computer to be shut down, the problem still persisted. Unplugging the wireless mouse (that was a new addition by the user and not the original supplied mouse) didn’t help either. In the end installing the latest intellipoint software and rebooting the machine fixed the problem. Just installing the software didn’t help.
It was nice that Windows7 had automatically found drivers, but it obviously needed the full software installed to work completely.
Subsequently we found a message popping up on the client pc that said the wireless signal strength was low – so it was probably the mouse trying to check in that was making the computer think activity was occurring on the pc.
I had a client’s LiveCommunicator 2005 stop working and part of the troubleshooting was to remove the software and reinstall. Unfortunately, when I went to reinstall the software, the installation was interrupted and did not complete. No errors were logged in the event log but by looking at the install log file and searching for “return value 3” (standard practise when debugging msi installs) I found the following “ActivateTimeBomb. Return value 3”. A google search only pulled back 3 results, all for Live Communicator which was a good sign, but I did find a posting on the appdeploy forums that offered a solution. I had already applied this patch to the server but had not needed to apply it to the client before, but doing so fixed the problem. The patch file can be found from the kb article 974571 or a direct download.
I was suprised to see how little information was available on google and how useless the install process was. The timebomb information was hidden away in the install log and knowing that “Return Value 3” was the key to a successful troubleshooting session.
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.
Yes I deliberately posted the date this way as that is how the shortsighted programmers as Symantec did it. Needless to say, when the year rolled around to 00101 this is a lot less that 91231 so the definitions were treated as old. It scares me to see that this bug managed to get into the product – did they not learn anything from the Y2K issues?
To make matters worse we found some servers were continually downloading definitions onto the server and in one case filled up 73gb of disk space. The fix for this is to ensure that the endpoint protection manager software is running 11.0.5 – this is a new download and upgrade installation although for one of our clients it meant uninstalling and reinstalling every single pc at that location – not an upgrade at all.
To top it all, Symantec also decided this week to announce the end of life for the v10 of their products – the only version that was actually working with correct definition dates. Although end of life is in 2012, support should really have coordinated with sales to ensure that the notice didn’t go out *this* week.
I think I still have a few servers that haven’t updated, so I will be checking those out next week. If we continue to use Symantec (which I really do not want to do), I’m hoping to look at an MSP installation of the product – one server managing all the clients so I only have one place to check for client status (and only one server to install, patch and configure)
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.
Today of all days we’ve had two clients that have had their server reboot for a couple of valid reasons but after reboot the server just sat at “preparing network connections” screen and would not continue. We’re not sure right now what caused this issue but the solution was to reboot the server, press F8 and choose the Last Known Good to be able to get into the server.
Today has not been a good day for this to happen as some clients have been closed so they’ve not been around to let us in to look at the server on site but at the same time we don’t really want to wait until Monday to get access to the server, yet this is a holiday weekend.
For me, it’s been a long week . I’ve started work at 4am twice this week and was working at 1am until 2.30am last night so I doubt I’ll be staying up for NewYear – but I think I can make it until 7pm when I’ll be able to watch BigBen strike midnight.
Happy New Year everyone and I hope 2010 starts off better than 2009 finished!