It might sound obvious, but it is often the little things that catch out even the best of us at times.
If you’re in a situation where you need to remove a server from a SharePoint farm, then re-join it to the farm again (perhaps to resolve some sort of local corruption of the site config), make sure you manually check that all remnants of SharePoint farm membership are removed before you try adding it again. Normally SharePoint keeps a fairly tidy house and cleans up after itself well – but occassionally it leaves something behind, and this can wreak havoc on your environment if not picked up. Depending on which server role you’re dealing with in the farm, this could mean websites and/or application pools in IIS, databases, web application folders on the filesystem, or a bunch of other things.
This tripped up a colleague of mine recently – in this particular case the Security Token Service was for some reason not removed when the server was removed from the farm. When the server was re-joined to the farm, there were no errors, or issues that suggested there was a problem, but things started falling apart shortly afterwards.
How we located the issue was that the search functionality within a SharePoint site on the farm started returning those lovely generic SharePoint errors, and digging through the logs we found that old chestnut “Object reference not set to an instance of an object”.
Removing the server from the farm again, manually removing STS from IIS (including its application pool), then re-adding the server to the farm solved the problem immediately. Presumably there was some GUID under the hood that binds the STS to the farm, and as a result of the remove/join this GUID got out of sync with reality.
SharePoint 2010TipsTraps For Young Players
Removing server from SharePoint farm
March 23, 2011
SharePoint
No Comments
gingerninjanz
It might sound obvious, but it is often the little things that catch out even the best of us at times.
If you’re in a situation where you need to remove a server from a SharePoint farm, then re-join it to the farm again (perhaps to resolve some sort of local corruption of the site config), make sure you manually check that all remnants of SharePoint farm membership are removed before you try adding it again. Normally SharePoint keeps a fairly tidy house and cleans up after itself well – but occassionally it leaves something behind, and this can wreak havoc on your environment if not picked up. Depending on which server role you’re dealing with in the farm, this could mean websites and/or application pools in IIS, databases, web application folders on the filesystem, or a bunch of other things.
This tripped up a colleague of mine recently – in this particular case the Security Token Service was for some reason not removed when the server was removed from the farm. When the server was re-joined to the farm, there were no errors, or issues that suggested there was a problem, but things started falling apart shortly afterwards.
How we located the issue was that the search functionality within a SharePoint site on the farm started returning those lovely generic SharePoint errors, and digging through the logs we found that old chestnut “Object reference not set to an instance of an object”.
Removing the server from the farm again, manually removing STS from IIS (including its application pool), then re-adding the server to the farm solved the problem immediately. Presumably there was some GUID under the hood that binds the STS to the farm, and as a result of the remove/join this GUID got out of sync with reality.
SharePoint 2010TipsTraps For Young Players