SharePoint 2010: Missing Links in Central Administration
Today 03/14, I came across this scenario, and wanted to post something up as it will make you second guess your SharePoint configuration [and sanity]. I have SharePoint 2010 hosted on my Windows 7 laptop. In my Favorites Bar in IE, I created a SP2010 folder, and in that folder, I add a favorite for Central Admin, and my SharePoint sites. Gives me an easy way to hit the sites I’m after while working on my laptop.
When I open IE and click my Favorite for Central Admin, I find that some links are missing. Clicking on some of the links that actually show up throw Access Denied messages, though others will work. The main link that is missing that I associate with this scenario is “Manage Services on Server” under System Settings. The “Configure incoming e-mail Settings” link will also be missing on that page.
You get: Servers> Manage Servers in this Farm
Expect this: Servers > Manage Servers in this farm | Manage Services on Server
Also, most of the Farm Backup and Restore links will be missing. Check out this screenshot. The following links are missing:
- Perform a Backup
- Restore from a backup
- Configure backup settings
You get: Farm Backup and Restore View Backup and Restore History | Check backup and restore job status
Expect this: Farm Backup and Restore Perform a backup | Restore from a backup | Configure Backup Settings | View Backup and Restore History | Check backup and restore job status
To make matters worse, you likely set this up a few weeks ago, and can’t quite remember if those links were there to begin with 
If you’re like me, you think, “I must have messed something up. Let me run the configuration wizard, and see if that gets things going.” If you do that, IE will launch after the wizard, and Central Admin will appear with all the links. You go on your merry way, and do whatever you were planning on doing. You come back a couple days later and the links are missing again. This is where questioning your sanity comes into play
I asked around, and found that the cause is a combination of the following:
- Browsing from the server hosting Central Administration
- UAC Enabled on the machine
- Opening the browser without elevation
- If you are browsing from a Windows Server hosting Central Admin, you also have IE Enhanced Security Configuration (ESC) to deal with as well.
The fix is to either:
- Launch Internet Explorer as Administrator (Right-click Internet Explorer, select “Run as Administrator”)
- Browse Central Admin, by clicking the SharePoint 2010 Central Administration link in the Start menu. This runs “psconfigui.exe –cmd showcentraladmin” which will force elevation.
I would think the majority of people that are going to hit this are developers working with SharePoint locally as most administrators will not be browsing directly from the server hosting Central Admin. From looking around, it appears the same behavior is seen with SharePoint 2007:
How to Install a software update for SharePoint Foundation 2010
Recently we encountered some issues with the SharePoint updates. Even though the previous update procedures may be quite successful you may somehow find new or additional issues after the updates. Please see the below link from Technet explains the procedures for various SharePoint Server 2010 updates.
Click Here to see the Procedure for Updates
Event ID 3351-Login failed for user ‘NT AUTHORITY\ANONYMOUS LOGON’
Today 01/04/2011, as part of my monthly checks, I noticed a whole bunch of 3351 errors in the event log on the SharePoint front end web server.
Event Type: Error
Event Source: Windows SharePoint Services 3
Event Category: Database
Event ID: 3351
Date: 1/4/2011
Time: 12:44:45 AM
User: N/A
Computer: MOSSSERVER
Description:
SQL database login failed. Additional error information from SQL Server is included below.
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
Resolution: First I started to check the application pool account of the portal site and found they were all set as defined. After a thorough investigation found that the Windows SharePoint Services VSS Writer account is running as local system account. Changed the account to the AD Farm Account and found that the issue is resolved.
Plan SharePoint Server disaster recovery (DR Plan)
When creating a disaster recovery (DR) plan, you need to determine what you are trying to recover from. In other words, think of your disaster recovery plan as "taking out insurance" for your SharePoint environment. There are various levels of protection you might wish to set in place. You may be using a DR plan to create a replica of your portal to recover specific content, or you may wish to develop a plan to create a new environment from scratch (in the event of an actual disaster) that will quickly and effectively replicate the current environment.
For example, on one end of the spectrum, you could make things easy on your operational team and back up your data once every six months or so, but then you run the risk of losing a lot of data if something were to happen (a hard drive crashes, you lose power, and so on). On the other end of the spectrum, you can do a full backup of everything daily to ensure that you always have the latest of everything—but does that make sense for your environment?
To properly capture these types of decisions, we recommend creating a DR operations document.
The following is a framework for a SharePoint disaster recovery document. It is important to note that a DR plan is only effective if it is both complete and accurate.
An effective SharePoint DR plan should contain full documentation on how to recreate an entire SharePoint environment from scratch. This requires a process (and discipline) that is accurate and well-maintained. Every time a SharePoint element (for example, a Web part, xml file, and so on) is altered or added, the "disaster recovery inventory document" must be updated.
Sharepoint Administrative Tasks
I have been asked many a times what is the role of Sharepoint Administrator. In my opinion the Sharepoint Administrator primary job would be to monitor and check the Sharepoint Servers and Sharepoint Access, Build up the Physical Architecture, Logical Architecture and creation of SIte Collections and Sites and Management of Content Databases as per the best practices suggested by Microsoft.
- Some of the Routine SharePoint administrative tasks would be:
- Daily checks to test and monitor the SharePoint Status, health, and the Performance (SharePoint sites Response time, status of host server, SharePoint Server and the IIS Server)
- Daily check of Front-end and Back-end backups for business continuity.(Check the last date of your backups)
- Daily Check of the profile import.
- Daily check of the Search and Indexing features.
- Daily check and installation of Security Updates.
- Daily check the SharePoint Site Access
- Daily Monitoring and Reporting of SharePoint Sites.
- Daily Monitor and analyze SharePoint usage and activity.
- Daily Monitor and analyze SharePoint content and storage.
- Daily Monitor SharePoint Trends and Governance Violations.
- Daily monitor event logs for any errors or warnings. Make sure the number of warnings and errors were minimum and health check of the Sharepoint environment.
Issues after restoring MOSS to a previous VM snapshot
We restored our VM MOSS farm this morning from a snapshot taken a couple of months ago. Various issues occurred. Please note i am still working through some of the errors and will update this post as i find the answers.
- I could no longer login to the server because the snapshot was older than 30 days - the computer account for the server had expired and so needed to be reset and reconnected to the domain. See this blog for steps to fix this.
- The MOSS environment although appearing correct in Central Administration was not configured in IIS. The Central Administration site was the only site appearing in IIS even though all the web applications were still there.To fix this:
- Delete the old web application using Central Administration.
- Delete all the SSP web apps & DBs, apart from the default SSP which cannot be deleted.
- Recreate the web applications with Temp DB names.
- Recreate the SSPs with new DBs.
- Change the default SSP to one of the newly created SSPs, then delete the original default SSP inc DB, then recreate it's web app and set back to the default updating any associations as required.At this point I ran in to some issues recreating the SSP with the following errors. First of all the SSP failed to provision with the error:
Provisioning failed: A transport-level error has occurred when sending the request to the server.
Best Practices for SharePoint Backup & Recovery
AvePoint Doc Ave-SharePoint Backup Tool
Backing up SharePoint-related SQL Server databases
Backing up SharePoint-related SQL Server databases
I recently came across this artice by Ross very nicely explained about the backup of SharePoint related to SQL Server Databases.
SharePoint administrators often make good use of the included tools when backing up and restoring SharePoint-related SQL Server databases. However, these tools cannot be used to restore a full SQL Server installation to the point of failure. To overcome this obstacle, SharePoint administrators should be aware of the following SQL Server elements:
|