fighting working with SharePoint for about a week and trying to get the Search Service started on my SharePoint Server. The only thing that seemed consistent in all the troubleshooting was that the SharePoint error messages were only slightly more helpful than “An error has occurred”. I ended logging a PSS support call with Microsoft and didn’t get very far for a while. My SharePoint farm consisted of the SharePoint Server and a separate SQL server to host the data and attempting to start the service I would get ‘Could not access the Search administration database. A generic error occurred while trying to access the database to obtain the schema version info.’
There are several other posts out there on updating the version of SharePoint to the latest Service Pack, Installing the latest cumulative update(2598321) and ensuring that the protocols were enabled on the SQL instance. All things I corrected, applied and did not fix the issue. (Note that installing the latest cumulative update DOES require a reboot and may stop SharePoint working until you do reboot – so make sure you install this out of hours.)
Upgrading the database is done with ‘psconfig -cmd upgrade -inplace b2b -force -cmd applicationcontent -install -cmd installfeatures’ After running this command I noticed that the checking the status of the server with (get-spserver servername).NeedsUpdate would work fine on the SQL server, but running against the SQL server from the Sharepoint Server, it would tell me the database needed updating.
On one of my servers, Add/Remove Programs said that the hotfix was not required yet the Admin console on the website said it was. This issue was fixed with a “psconfig -cmd installcheck -noinstallcheck” (Thanks to http://tinyurl.com/7pkrbem)
After starting the service on the sql server instance, we wanted to get the SharePoint Server working as originally intended. After a long time of troubleshooting, our next step was to uninstall the SQL Native Client and reinstall it. As I went to uninstall the Native Client, Add/Remove programs told me the package was not installed. A repair or modify would not work either. Opening Regedit and searching for Native Client under HKey_Classes_Root\installer and deleting this key meant I was then able to reinstall the NativeClient.
We then tried starting the service and this time it worked. The strange thing is that some communications between the SharePoint server and the SQL server were obviously working fine – the database on SQL was created with no problems and SharePoint could see the data – it’s just weird that the initialising/upgrading of the database required the SQL native client but did not give any useful information that pointed to this fact.
After several hours of work today, Powerpoint suddenly gave the error message “PowerPoint was unable to display some of the text, images, or objects on slides in the file, filename because they have become corrupted. Affected slides have been replaced by blank slides in the presentation and it not possible to recover the lost information. To ensure that the file can be opened in previous versions of PowerPoint, use the Save As command (File menu) and save the file with either the same or a new name.”
Now it is all very well giving a really verbose error message, but to totally blank out slides and wipe out missing data is a very peculiar way of fixing the issue. It looks like a hotfix was released in May 2011 but in our case, I saved the file to a usb drive, copied it across to my machine that had office 2010 installed and then opened the file in Powerpoint 2010. I was able to open the file but this time I got another warning about some data being corrupted but the slides that were empty in 2003 were displayed ok. I then resaved the file back to a new filename on the usb drive, opened the new file back in 2003 and we were really relieved to have a working powerpoint file to continue working on.
Not only is the data back, it also means another 4 hours of work does not need to be repeated and instead more time can be spent surfing waves – a great result all around.
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.
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.