How to determine MS Sharepoint server version / patch level over HTTP

Hello,

I need to confirm a version of a remote Sharepoint server. I understand this can be done by looking at HTTP header as well as the content of /_vti_pvt/service.cnf file.

In the past the server was responding with the following HTTP header:

  GET /SitePages/***
  Host:***
  ...
  HTTP/1.1 200 OK
  MicrosoftSharePointTeamServices: 15.0.0.4420

And /_vti_pvt/service.cnf file contained

  vti_encoding:SR|utf8-nl
  vti_extenderversion:SR|15.0.0.4481

Based on this the owner of the server was advised to upgrade to the latest version to eliminate known security issues.

Now, on a supposedly upgraded server, HTTP header is exactly the same, but /_vti_pvt/service.cnf file contains:

  vti_encoding:SR|utf8-nl
  vti_extenderversion:SR|15.0.0.4641

I have the following questions:

Why different version are reported in these two locations?

Why the verion is reported as 15.0.0.NNNN, while in most documents they are referred to as 15.0.NNNN.MMMM and how to correlate the two?

Thank you.
LVL 3
gremwellAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

btanExec ConsultantCommented:
Taking example, the version number is 14.0.0.6114, this corresponds to SharePoint 2010 (14) and December 2011 Cumulative Update (6114). In fact, the version is more accurately reads as 14 as the major, 0 as minor, 6114 as build and if there is another appending number, it is the revision.  So it can still be as accurate based on just (major).(minor).(build).(revision).
 
Check out the listing in example and note the various Sharepoint package version inclusion http://blog.fpweb.net/what-sharepoint-version-am-i-using/
http://toddcarter.net/sharepoint-versions/
 
As a whole, the one in http header follow the header not added by SharePoint but rather by IIS, even though it is SharePoint who adds it to IIS. The value is also in the registry so if it is given as  (major).(minor).(build), this will be returned and so far this is the norm default unless it is customised specifically.
 
If you check the Central Administration Web Site you’ll it also have the same exact version value. But it is not always as simple as we understand in a load balanced situation as version may not be readily updated. Check this post where the version is updated based on the login account to perform the upgrade.
 
http://www.wictorwilen.se/sharepoint-mythbusting-the-response-header-contains-the-current-sharepoint-version
Deep down between the zeroes and ones in the SharePoint code there is actually a code snippet that checks if the account running the upgrade is a member of the local Administrators group. If the account is member it will nice and quietly update the IIS metabase with the (file) build number, taken from the current assembly which is Microsoft.SharePoint.dll. But if the user is not a local Administrator (and cannot edit the metabase), the operation is passed on to the WSSAdmin component (running as Local System) which uses another assembly. This assembly is called Microsoft.SharePoint.AdministrationOperation.dll, and the metabase is updated with the (file) build number for that assembly.
So there you have it – you cannot trust this MicrosoftSharePointTeamServices response header as a single source of trust when you need to remotely find out your SharePoint build and version. Even if you keep track of all the specific builds of the administration assembly, since it might not be updated, and you cannot be sure that everyone runs psconfig with the –wait switch.

I shall not really bother with the .cnf as it is still the dll that determine and regardless the build vs revision it should really matters if the patch is done accurately and correctly, (and no foul play of course to manipulate the header).
 
Actually this version embedding into http header is double edge as the adversary will also know about its existing version, it can still be managed so as not to be over revealing. Nonetheless, I understand that if you remove the “MicrosoftSharePointTeamServices” totally SharePoint search will not work. Kind of "chicken and egg" situation.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
gremwellAuthor Commented:
Thank you for your response, it clarifies the situation a bit.
Looking at /_vti_pvt/service.cnf seems to be a bit more reliable approach.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft SharePoint

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.