none
a Sharepoint Timer Job called “Product Version Job”

    Question

  • I can’t seem to find a good explanation of what the SharePoint Timer Job called “Product Version Job” does and what significance it has for the system.  I like others are seeing many errors in the event log and I would love to simply disable this task.  Before I do I would like to know what will no longer work in SharePoint as a result.

     

    Does anyone have a good description?

    Thanks in advance

     

    • Moved by Mike Walsh FIN Thursday, December 30, 2010 9:05 AM SP 2010 questions go only to SP 2010 forums (From:SharePoint - Setup, Upgrade, Administration and Operation (pre-SharePoint 2010))
    Friday, November 26, 2010 5:14 PM

Answers

  • This has been a long process (it should not have been, but it was).  Hopefully it will help others to understand what this task does.  This thread however is long, so I'm hoping it won't be overlooked for those wishing to seek the answer... 

    From my engagement with Microsoft on this issue:

    > what the job's purpose is and what it does in Foundation ?
    >
    >
    >
    > Purpose : The timer job “Product Version Job” put the updated software version information from the SharePoint Server on to the SharePoint Databases. 
    >
    > Scenario : Say a SharePoint Update got installed on the SharePoint Server by a user or by windows update. Then after running the SharePoint Product and Technology Configuration wizard the SharePoint product binaries i.e. .dlls gets updated to the new version located on files system C:\windows\assembly, C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI, C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN, C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\CONFIG,  C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Policy i.e. mostly in 14 folder.          
    >
    > The Timer Job “Product Version Job” runs every night at 12:52 A.M and analyze which are the dlls are updated, once it get the information then it’s put the updated version data on to Content Database “dbo.version” table.
    >
    >
    >
    > Example : Version name of SharePoint 2010 RTM on Central Administration > Manage Servers in the Farm > you will find the SharePoint Configuration database version 14.0.4762   
    >
    > Now if you open SQL Management Studio > connect to the SharePoint
    > instance > locate the configuration database > open the table
    > “dbo.versions” you will find the same version 14.0.4762
    >
    >
    >
    > Hence putting the updated version name from SharePoint Server on to the SharePoint Databases is the Job of “Product Version”
    >
    >
    >
    >
    >
    >
    >
    > It does the same operation in SharePoint foundation as it does in SharePoint 2010.
    >
    >
    >
    > I can't find out why it is running in the first place ?
    >
    > If the job “Product Version Job” will not run then there may be an issue on product version mismatch during certain server level operation.
    >
    > I think if you will not run this job then you might face below error while upgrading your Server Farm as the SharePoint Server and Database version will not match with each other. 
    >
    > Event Type: Error
    > Event Source: Windows SharePoint Server Event Category: Topology Event
    > lD: 5617
    > Description:
    > The schema version (3.x.x.x) of the database SharePoint_AdminContent_123fda45-f456-fad5-de45-7891d2asd455 on ComputerName is not consistent with the expected database schema version (3.x.x.x) on ComputerName. Connections to this database From this server have been blocked to avoid data loss. Upgrade the web Front end or the content database to ensure that these versions match.
    >
    >
    >
    > Similar below error message can be notice while upgrading your farm considering a multiple Server Farm environment.  
    >
    >
    >
    > There was a mismatch in Version Id Application server AAA and Web front End Server BBB. AAA is showing version as 14.0.5123 and the web front end server BBB will be showing Version id as 12.0.0.4762.
    >
    >
    >
    > What (if anything) would be lost if I disabled it ? 
    >
    > I will  try disable the “Product Version Job” on my lab machine and check what negative impact it has on the SharePoint Server.
    >
    >
    Disabling has confirmed that the site will work correctly, until you attempt any upgrades.

    If I could mark this as the anwer I would...

    cheers


    • Marked as answer by Mike Walsh FIN Thursday, December 30, 2010 9:04 AM
    Wednesday, December 29, 2010 8:39 PM

All replies

  • You can check the following articles for a possible solution.

    Note the following articles are for SharePoint 2010, as mentioned you can check them for a possible solution.

    Product Version Job: DCOM 10016 strikes again

    and 

    Fix the SharePoint DCOM 10016 error on Windows Server 2008 R2

    Hope that helps.

    -Mukesh


     

     

    Saturday, November 27, 2010 9:47 AM
  • Thanks Mukesh, I have seen those articles before I posted.  You will note that neither actually provide an answer, and more important a good description of what this timer task does (although in the second article the author gives his version after reverse engineering the code).

    What I am hoping someone can answer is what does this timer task do, and what is the "cost" of disabling it in SP?

    I, like the authors of the other posts you noted, do not want to simply "grant" install rights to this.  As pointed out, that opens up a potential security issue.

    I'm hoping maybe a SP MS developer will respond, or the moderator can ping someone in the MS Dev group to help as there are many posts in various forums asking this question.

    Again, thanks for the reply...

    cheers

    Saturday, November 27, 2010 6:20 PM
  • Does anyone have any suggestions on how to find out more about this job?

    I'm amazed at how "mysterious" it seems to be...

    Hoping for a repsonse....

    Monday, November 29, 2010 9:03 PM
  • That particular timer job is listed here with a description:

    http://technet.microsoft.com/en-us/library/cc678870.aspx

    Tuesday, November 30, 2010 12:28 AM
  • Thanks Sephiroth, but I have seen that as well.  "Checks the installation status of the computer and adds that data to the database"

    Not a very useful or insightful description of what the job's purpose is and what it does in Foundation.  This job seems rather nebulous.  I can't find out why it is running in the first place.  I get what the description says, but why is this needed, but what resources in Foundation and when?

    Do you know?

    What (if anything) would be lost if I disabled it?  I have yet to find anything describing this.

    Thanks in advance

    Tuesday, November 30, 2010 2:08 AM
  • Unfortunately, I'm not familiar with that particular job.  I did find another thread discussing your exact same issue though:

    http://social.technet.microsoft.com/Forums/en/sharepoint2010setup/thread/63539a2a-bdee-466c-9ff3-07c1eecfcbd4

    You could try pinging the user who posted this thread from August to see if they ever found out what the job was doing and if any issues resulted from disabling it (thread was from August).

    Tuesday, November 30, 2010 2:12 PM
  • This has been a long process (it should not have been, but it was).  Hopefully it will help others to understand what this task does.  This thread however is long, so I'm hoping it won't be overlooked for those wishing to seek the answer... 

    From my engagement with Microsoft on this issue:

    > what the job's purpose is and what it does in Foundation ?
    >
    >
    >
    > Purpose : The timer job “Product Version Job” put the updated software version information from the SharePoint Server on to the SharePoint Databases. 
    >
    > Scenario : Say a SharePoint Update got installed on the SharePoint Server by a user or by windows update. Then after running the SharePoint Product and Technology Configuration wizard the SharePoint product binaries i.e. .dlls gets updated to the new version located on files system C:\windows\assembly, C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI, C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN, C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\CONFIG,  C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Policy i.e. mostly in 14 folder.          
    >
    > The Timer Job “Product Version Job” runs every night at 12:52 A.M and analyze which are the dlls are updated, once it get the information then it’s put the updated version data on to Content Database “dbo.version” table.
    >
    >
    >
    > Example : Version name of SharePoint 2010 RTM on Central Administration > Manage Servers in the Farm > you will find the SharePoint Configuration database version 14.0.4762   
    >
    > Now if you open SQL Management Studio > connect to the SharePoint
    > instance > locate the configuration database > open the table
    > “dbo.versions” you will find the same version 14.0.4762
    >
    >
    >
    > Hence putting the updated version name from SharePoint Server on to the SharePoint Databases is the Job of “Product Version”
    >
    >
    >
    >
    >
    >
    >
    > It does the same operation in SharePoint foundation as it does in SharePoint 2010.
    >
    >
    >
    > I can't find out why it is running in the first place ?
    >
    > If the job “Product Version Job” will not run then there may be an issue on product version mismatch during certain server level operation.
    >
    > I think if you will not run this job then you might face below error while upgrading your Server Farm as the SharePoint Server and Database version will not match with each other. 
    >
    > Event Type: Error
    > Event Source: Windows SharePoint Server Event Category: Topology Event
    > lD: 5617
    > Description:
    > The schema version (3.x.x.x) of the database SharePoint_AdminContent_123fda45-f456-fad5-de45-7891d2asd455 on ComputerName is not consistent with the expected database schema version (3.x.x.x) on ComputerName. Connections to this database From this server have been blocked to avoid data loss. Upgrade the web Front end or the content database to ensure that these versions match.
    >
    >
    >
    > Similar below error message can be notice while upgrading your farm considering a multiple Server Farm environment.  
    >
    >
    >
    > There was a mismatch in Version Id Application server AAA and Web front End Server BBB. AAA is showing version as 14.0.5123 and the web front end server BBB will be showing Version id as 12.0.0.4762.
    >
    >
    >
    > What (if anything) would be lost if I disabled it ? 
    >
    > I will  try disable the “Product Version Job” on my lab machine and check what negative impact it has on the SharePoint Server.
    >
    >
    Disabling has confirmed that the site will work correctly, until you attempt any upgrades.

    If I could mark this as the anwer I would...

    cheers


    • Marked as answer by Mike Walsh FIN Thursday, December 30, 2010 9:04 AM
    Wednesday, December 29, 2010 8:39 PM
  • >Does anyone have any suggestions on how to find out more about this job?

    >I'm amazed at how "mysterious" it seems to be...

     

    One of the reasons why you are not getting responses that suit your needs is that you posted this question to a pre-SP 2010 forum. So people have been assuming you have MOSS 2007.

    What's become clear from your posts since that first post (for instance saying that you read a couple of *2010* posts before posting here) is that you actually have SP 2010.

    In other words you should have posted this question to a SP 2010 forum. Then it would not have been so "mysterious".

     

    (Moderator pre-SP 2010 forums, who will now move this thread to a SP 2010 forum - please in future post SP 2010 questions directly there)

     

     


    SP 2010 "FAQ" (mainly useful links): http://wssv4faq.mindsharp.com/default.aspx
    WSS3/MOSS FAQ (FAQ and Links) http://wssv3faq.mindsharp.com/default.aspx
    Both also have links to extensive book lists and to (free) on-line chapters
    Thursday, December 30, 2010 9:03 AM
  • Hi Geoff,

    That's good stuff. At least we have confirmation that the job isn't used for anything else. That was pretty much what I assumed from the MSDN info but I had no idea if that was a comprehensive description.

    One thing I'm concerned about is whether your database is actually getting updated when you get these errors. What I mean is, when you run the job, is it actually updating the database with the correct version info? Do these DCOM errors mean that the job is failing to update the database successfully or are they ephemeral? I would test this myself but I'm on leave for the next few weeks and don't have access to a test system. I'd be curious to know what you find. If it isn't updating the database, then we have another problem altogether!

    Cheers,

    Tristan

    Thursday, January 06, 2011 1:19 AM
  • Hi Tristan,

    As best I can tell, if your getting the DCOM error, then no the DB is not updated.  If you change the security (i.e. local admin for SP account) then the errors go away, and the DB is updated. 

    As per Mike Walsh however, I should note that no matter what search engine you use you won't find the information I got when I finally paid for Microsoft to tell me.  It's just not out there, but in my opinion, MS should have this clearly documented.

    That's a hint if MS is listening...

    cheers

    Thursday, January 06, 2011 4:41 PM
  • > As per Mike Walsh however, I should note that no matter what search engine you use

    Perhaps you should read my post again. I said that because you posted this question in a pre-2010 forum, you were getting answers for MOSS 2007. If you had posted it (originally) to a 2010 forum the answers you had received here would have been for the product you have.

    There was no mention in my post of search engines.

    Mike Walsh


    SP 2010 "FAQ" (mainly useful links): http://wssv4faq.mindsharp.com/default.aspx
    WSS3/MOSS FAQ (FAQ and Links) http://wssv3faq.mindsharp.com/default.aspx
    Both also have links to extensive book lists and to (free) on-line chapters
    Thursday, January 06, 2011 5:11 PM
  • The more I consider this job the more I'm confused by the answers above. Presumably, the databases get upgraded when the first server in the farm receives the update since the Setup account does have administrative privileges, which means we don't have any problems with the least-privileged security model. Presumably subsequently-updated servers will get the new binaries, registry settings, etc, but I would be very surprised if the databases remain at the old version number until after *all* servers in a farm have been updated and this job runs successfully. That sounds like madness. The databases must get updated when the first server in the farm gets patched successfully. I'm pretty sure SharePoint Products and Technologies Wizard does this for the first server.

    So if the databases get the new version number during the update, one would assume that the only purpose of this job is to check for inconsistencies from failed updates. If that's the case, then living without the job becomes less problematic, i.e. it can still be run with administrative rights before upgrades.

    It's late and I may not be thinking this through clearly, but I'm pretty sure this means that the DCOM errors are not a big deal, other than their clutter and running the job before upgrades, as I originally supposed. If all of this is wrong, then we have a real problem because the only way to get this job to run automatically (out of the box) is to grant installation rights to the farm account.

    Friday, January 07, 2011 1:50 AM
  • Hi Geoff,

    I've finally finished looking in to this in more detail, and got some clarification on the security implications of modifying the DCOM rights along the way.

    Inside Manage Patch Status

    Testing Manage Patch Status

    Cheers,

    Tristan

    • Edited by Tristan Watkins Sunday, February 20, 2011 7:09 PM Tidied up links
    Sunday, February 20, 2011 6:45 PM