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.
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.
We had an issue when all of a sudden we were not able to remote desktop to a clients SBS 2008 server using the rdp client and the TSGateway functionality. Remote Web Workplace would work fine and so would Windows7 clients.
After proving this patch was the culprit by removing the patch and finding my saved rdp session would work, I went back and read the kbarticle 969084 on this patch. I hadn’t initially read this (in common with a lot of other people) and also because the patch was pushed down via wsus. It turns out that XP does not turn on CredSSP by default and this is needed to work with the new RDP client. I followed the instructions at kb951608 and after a reboot, going to the control box/About I got the message that Network Level Authentication was supported and I was then able to connect succesfully.
To summarize you need todo the following.
- Click Start , click Run , type regedit , and then press ENTER.
- In the navigation pane, locate and then click the following registry subkey:
- In the details pane, right-click Security Packages , and then click Modify .
- In the Value data box, type tspkg . Leave any data that is specific to other SSPs, and then click OK .
- In the navigation pane, locate and then click the following registry subkey:
- In the details pane, right-click SecurityProviders, and then click Modify .
- In the Value data box, type credssp.dll . Leave any data that is specific to other SSPs, and then click OK .
- Exit Registry Editor.
- Restart the computer.
We rolled out IE8 to a customer earlier this week and promptly found their company website didn’t work in ie8 (despite some users having had IE8 for several months). An imagemap that they use for navigation did not show up in IE8 on internal computers. The weirdest thing is that all the computers at their office had the problem yet none of our computers or some other computers we tried could reproduce the problem.
After trying many technical solutions I passed it to our web developer who very quickly came up with a bug in ie8 and content produced by Publisher
“Publisher HTML output uses some very large numbers for object coordinates. This behavior has worked in the past. However, Internet Explorer 8 does not support such large coordinates. This is because some precision was moved from the most significant end to the least significant end of the coordinate variables to allow for sub-pixel layouts. Therefore, when large coordinate values in Publisher HTML output are run through Microsoft Dynamic HTML, the values are truncated. This behavior causes significant problems when Publisher HTML is rendered in Internet Explorer 8.”
Sure enough – saving the files within Publisher 2007 sp2 fixed the issue.
“Your Out of Office settings cannot be displayed, because the server is currently unavailable. Try again later” occurs when trying to access out of office onwith outlook2007. The strange thing is that the out of office functionality through the Outlook Web Access page works as expected.
There are several documented ways to fix this, mainly ensuring that the various autodiscover urls are correct. See Proexchange.be – Your out of office settings cannot be displayed for the best document on this.
Interestingly is that if you enable debugging in outlook and try to access the Out of Office you do see the settings being pulled across in the logfile.
However I was still having this issue. From Microsoft forums on Exchange Server Clients I found that various patches to the dot net framework (oh how I hate thee) being discussed and http://support.microsoft.com/kb/952883 was the first patch that was discussed. Sure enough, installing this patch fixed the problem and what is more I didn’t even have to reboot.
The annoying thing is that the first time I had this problem (on this server) was due to a typo in the autodiscover service, then the .net framework patches were applied and the problem re-occured.
The past two reboots (where the server has been offline for a while) has resulted in non delivery reports being sent back to some of the mailboxes for mail that was sent several weeks ago and that had not been reported as failed when the mail was initially sent.
The first time this happened I thought it was just one of those things, especially as I had not seen mail in the queue before rebooting the server. After the second occurrence I knew it was time to investigate.
SBSisyphus has a great posting including a link to the exchange2003 (sp2) patch that should fix the “kb950757 Email senders do not receive an indication that some messages have been held by Exchange Server 2003 until the SMTP service, The Microsoft Exchange Information Store service, or the Exchange server is restarted”. I applied it to my machine and I’ll have to see what happens.
For what it’s worth you do not need to reboot the server (unless wmiprvse.exe is running – but you get an option to kill this process if it is running before proceeding) but it will stop and start your mail and web services so don’t apply it during the day and it goes without saying that you should have a backup first.
It’s been a very long weekend. I’ve been trying to do a migration from nt4 and exchange 5.5 up to Windows 2003 64bit, Active Directory and Exchange2007 and although I succeeded there have been several large hiccups along the way. More details in the extended entry as it will get technical!
Read more »
If you have outlook and try to print an email and the font is incredibly small, then you will need the hotfix from kb932538 referenced in the article on Sandy’s page. I would link to the Microsoft site but the knowledge base article is not published which explains why you can’t find any details on this problem when you search in technet (sigh).
I’ll be requesting this one for my customers on Monday morning as I have at least two desktops that are having this problem. The interim solution is to hit reply or forward and then print the email.
Update I installed this patch on a customer site this morning and it approximately doubles the size of the font so the printout is now just about readable – still nowhere near the size of the printout if I hit forward (or reply) and then hit print. I’m not sure how to go about sending feedback to Microsoft that this doesn’t solve the problem.
I knew there was a problem with using folder redirection and customizing internet explorer via group policy but I didn’t realise there was a hotfix available for it (it’s been around for quite some time looking at the date of the hotfix)
In the 2 months I’ve been working I’ve had to request 3 different hotfixes which is pretty amazing seeing as though I think I’ve only ever requested 2 in the past 10 years!
The latest is to fix a patch where you can’t set folder redirection and customize the Internet Explorer settings via group policy on an xpsp2 machine. If you try, then you get the message “The Group Policy client-side extension Internet Explorer Branding failed to log RSOP (Resultant Set of Policy) data. Please look for any errors reported earlier by that extension.” (event id 1091)
The hotfix is documented in kb article 888254 and I’m waiting for Microsoft to pick up the phone so I can request the hotfix.
Eventually the phone was picked up and I spent 10 minutes painfully talking to someone who actually sounded just like one of those automated phone systems. All the accents were on the wrong syllables and it was just painful. Still I’ve got the hotfix.