none
Multiple errors from MsiInstaller with event id 1015 and text "Failed to connect to server. Error: 0x80070005"

    Pregunta

  • Hi,

    Every night I get a lot of warnings in the event log from MsiInstaller with event ID 1015 and text "Failed to connect to server. Error: 0x80070005". They are always followed by a new event 1035. Example:

    Event 1015, MsiInstaller (Warning)
    Failed to connect to server. Error: 0x80070005

    Event 1035, MsiInstaller (Information)
    Windows Installer reconfigured the product. Product Name: Microsoft Excel Mobile Viewer Components. Product Version: 14.0.4763.1000. Product Language: 0. Manufacturer: Microsoft Corporation. Reconfiguration success or error status: 0.

    I probably get around 50 of these each night, and the 1035 events are all related to various SharePoint components. The user in all cases is the sharepoint farm account.

    I use SharePoint 2010 enterprise in a farm install on one virtual server. I have a private domain, and the database is on a separate server.

    Does anyone have any idea why this happens? Other than the error in the event log I cannot see any issues with my installation. I have searched for this error and seen it related to user profile synchronisation, but profile sync is working fine for me. I installed using the Technet guide and the user profile sync guide at http://www.harbar.net/articles/sp2010ups.aspx

     

    Thanks,

    Mikael

    martes, 27 de julio de 2010 8:35

Respuestas

  • Hi,

    I've been looking for solution to this issue since few days :/ and finally end up adding Farm System Account to local administrators on all farm servers.

    -> test immediately after setting admin rights failed !

    -> have rebooted all servers and repeated the test. It's finally passed. 

    I have decided to keep admin rights until finding exact config steps for this.

     

    Cheers,

    Dimitri

    • Marcado como respuesta Mikael André lunes, 27 de junio de 2011 6:54
    lunes, 03 de enero de 2011 21:39

Todas las respuestas

  • Hi,

    Kindly do this

    Method 1:
    1. Click Start, click Run, type services.msc, and then click OK.
    2. Locate and right-click the Background Intelligent Transfer Service, and then click Properties.
    3. Select Automatic startup type.
    4. Restart computer.

    Method 2 (i think it was this method that fixed it):
    1. Click Start, click Run, type services.msc, and then click OK.
    2. Locate and right-click the Remote Procedure Call (RPC) service, and then click Properties.
    3. On the Log On tab, click Local System account, click Apply, and then click OK.
    4. Restart computer. (this step was added by me)

     

    I hope this will work.

     

    Regards.

    Shafaquat Ali.


    M.C.I.T.P Exchange 2007/2010, M.C.I.T.P Windows Server 2008, M.C.T.S OCS Server 2007 R2, Phone: +923008210320
    martes, 27 de julio de 2010 9:37
  • Hi Shafaquat Ali,

    Thanks for the reply. The BITS service had startup type "Automatic (Delayed start)", and I changed this to automatic.

    All options for the Remote Procedure Call service are grayed out, any idea what I need to do in order to modify them? I am logged on as a domain administrator, and the server is running Windows Server 2008 R2.

    Also, do you know how I can verify if it works, other than waiting and see if the errors appears tonight?

     

    Br,

    Mikael André

    martes, 27 de julio de 2010 11:33
  • You probably need to be a domain admin on the server to change the settings for that service.
    martes, 10 de agosto de 2010 15:50
  • Yes, but I did this when logged in as domain admin..

    martes, 10 de agosto de 2010 20:06
  • Does this thread and sub thread help you at all?

    http://social.technet.microsoft.com/Forums/en-US/sharepoint2010setup/thread/dacb4d0c-817b-42cd-8c29-f6fc4c38904a


    Alpesh Nakar's Blog Alpesh Just SharePoint Just SharePoint Updates

    SharePoint Conference Southeast Asia Oct 26-27 2010 Contributing Author SharePoint 2010 Unleashed

    MCTS: SharePoint 2010 Configuration MCITP: SharePoint 2010 Administrator

    jueves, 12 de agosto de 2010 2:03
  • I do not know how to fix this, but at least I can tell how to check whether it is fixed: run "Product Version Job". The best summary that I have found on this topic: http://tristanwatkins.com/index.php/product-version-job-dcom-10016-strikes-again/. My conclusion is that currently no satisfactory solution is known. You either ignore the warnings, or disable the timer job. Which option to choose is a matter of taste.

    Kind regards,

    Janis

    viernes, 15 de octubre de 2010 7:14
  • Hi,

    I've been looking for solution to this issue since few days :/ and finally end up adding Farm System Account to local administrators on all farm servers.

    -> test immediately after setting admin rights failed !

    -> have rebooted all servers and repeated the test. It's finally passed. 

    I have decided to keep admin rights until finding exact config steps for this.

     

    Cheers,

    Dimitri

    • Marcado como respuesta Mikael André lunes, 27 de junio de 2011 6:54
    lunes, 03 de enero de 2011 21:39
  • Hi Janis,

    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
    • Editado Tristan Watkins domingo, 20 de febrero de 2011 18:54 Tidied up links
    domingo, 20 de febrero de 2011 18:45
  • Dimitri's solution was also recommended to me by a Premier Field Engineer. He hadn't told me I would need to reboot after granting the Farm Account local admin rights. I did find this to be necessary just as Dimitri did, though.

    I was concerned with leaving the Farm Account as a local admin. The PFE said the "Product Version Job" timer job is only necessary when updates are made to the farm servers. As such, our plan is to disable this timer job and only give the Farm Account local admin rights when "Product Version Job" is ran manually. This should only be necessary after updates have been applied to the servers.

    When "Product Version Job" runs successfully, you will see the 1035 (Information) events, but the 1015 (Warning) events of "Failed to connect to server. Error: 0x80070005" should not appear.

       ---PaulE---

    • Propuesto como respuesta Dave Crosby jueves, 18 de abril de 2013 19:17
    lunes, 18 de abril de 2011 22:29
  • I can confirm that adding the Farm Admin account to the local administrators group worked for me too.

    What's odd, is that some part of that process tries to connect to microsoft (cds??.syd9.msecn.net - we're in New Zealand, so Sydney is probably the local node on the content delivery network).  We're behind a corporate proxy, so this failes, regardless of the Farm Admin account being in the local admin group. And it doesn't appear to report it as failing...

    After letting the Office Web Apps complete a sucessful install, I've dropped the Farm Admin account out of the local admins.

    Someone at Microsoft probably needs to update THIS page.

    lunes, 13 de junio de 2011 23:48
  • Hi,

    Thanks to all who suggested adding farm admin account to the local administrators group. I can confirm that this worked for me as well, the Warnings in the event log disappeared, but I did of course get a new warning in central administration about service accounts with local admin permissions.. I agree with the suggestions made about making this a temporary change, and remove the account from the admin group after a successful installation.

     

     

    Mikael

    lunes, 27 de junio de 2011 6:56
  • Confirmed this on a new SP2010 install with Service Pack 1.  Any better fix for this?
    RobertRFreeman
    martes, 19 de julio de 2011 21:15
  • Hi,

    I already installed SP 1 with June CU, but still the problem the same ! . After long search, i could not find and fix for this problem, there is some workarrounds:

    1- To give Farm Account Local account administrator (Security Issue)

    2- Disable the Product Job Ver (Not recommanded)

    3- To run the job Product Job Manually from time to time after adding the the Farm Account to the local Administrator group (Temperary)

    Please if any one find a fix , post it here .

     

    Many Thanks.


    Abdul.
    domingo, 31 de julio de 2011 7:31
  • I'm seeing this as well, are the above work-around's still my only options?  The only realistic one is setting the farm account as a local admin, which I'd rather not do.
    martes, 18 de octubre de 2011 16:33
  • As detailed in the links above, a better answer than any of these three options is to grant Local Activation rights to the farm account on the Windows Installer DCOM rcomponent. To quote my blog post above: 

    How to fix it
    If you want to clear the DCOM 10016 errors by granting these rights, you need to assign ownership of HKCR\AppId\{000C101C-0000-0000-C000-000000000046}to Administrators, then grant Local Administrators Full Control. Now you’ll be able to grant the DCOM Local Activation rights to the Farm Account on this same{000C101C-0000-0000-C000-000000000046} component.

    I still think this is less than ideal from a least-privileged point of view, but preferable to granting local admin rights to the farm account. 

    jueves, 20 de octubre de 2011 21:22
  • I stubled across the fix above a couple of weeks ago and it didn't fix the problem for me. However, glad to see someone else trying the same thing and avoiding making the farm account a local admin. There's clearly something else also required and I'm still searching.
    viernes, 21 de octubre de 2011 9:19
  • I also have this issue.

    I can successfully elimate the many 1015 warnings from "Product Version Job" by adding the Farm Account to local administrators group on all farm servers.

    I really don't want to add Farm Account to local admins, so I hope somebody has another working solution.

     

    Best regards

    Thomas N. Sørensen

    miércoles, 14 de diciembre de 2011 13:10
  • Does anyone know of a safer solution to this issue?
    martes, 12 de junio de 2012 7:37
  • I'm still working on the MsiInstaller warnings but I've not cracked it, and am not sure if I will. I've detailed my efforts so far over here. Any other ideas or feedback would be more than welcome. 

    jueves, 14 de junio de 2012 15:52
  • What's safer than following the advice of a Microsoft Premier Field Engineer as I wrote about on April 18, 2011?
    martes, 19 de junio de 2012 4:00
  • I have exactly the same problem.
    I have tried to add local launch and activation rights to my account on the MSI component.
    I have tried this http://technet.microsoft.com/en-us/library/cc735600(WS.10).aspx

    None works...


    Gregory OTT => http://twitter.com/gregory_ott
    ALM Engineer at Tekigo => www.tekigo.com

    martes, 19 de junio de 2012 7:53
  • I guess that's a fair point :) I should have asked if anyone has come across a more permanent solution rather than a workaround you need to go through each time.
    miércoles, 20 de junio de 2012 2:54
  • So, nobody has found the actual solution for this? Other than just temporarily putting the farm account into the local admins group?
    miércoles, 20 de junio de 2012 18:49
  • Give Network Service read access to C:\Program Files\Microsoft Office Servers\14.

    http://sharepoint.nauplius.net

    miércoles, 20 de junio de 2012 18:59
    Moderador
  • Gave Network Service account read/execute/list permission to the 14 folder, and rebooted. Still no luck for me. Also gave the farm account the same just to see if that'd do anything. No luck.
    miércoles, 20 de junio de 2012 19:54
  • Hey Trevor, that just takes care of some similar errors that are generated by the FIM instance inside the User Profile Service App. The same approach doesn't seem to take care of the Product Version Job 1015 warnings, or at least I can't find the file location that causes the problem, if that is indeed the issue. I documented that over here a couple of weeks ago: http://tristanwatkins.com/index.php/failed-detection-people-ilm-components-user-profile-synchronisation-service-dcom-10016-errors/
    • Editado Tristan Watkins miércoles, 20 de junio de 2012 22:11 Forgot link
    miércoles, 20 de junio de 2012 22:10
  • @PaulE The problem is that the advice contradicts the advice that a lot of other qualified practitioners put forward. This isn't to say that it's wrong, but that the appeal to authority has at least equal validity when inverted. Given that the appeal to authority is insufficient, we need to inspect whether the risks of breaking the least privileged model are acceptable to each of us on account of a few *warnings* (not errors, which can be fixed) in the event logs.
    • Editado Tristan Watkins miércoles, 20 de junio de 2012 22:16 Directed comment
    miércoles, 20 de junio de 2012 22:14
  • That is a good way to view it, Tristan. They are indeed just warnings (annoying as they are to someone watching their event logs). If you're uncomfortable with the solution, just ignore the warnings: they aren't indicative of something that needs to be fixed. 

    I do use and understand the least privileged model, but I am comfortable with breaking that model for the 15 minutes it takes to add the farm account as an Administrator, reboot (not always necessary; but safest to do), run the "Product Version Job", and then remove the farm account from the Admistrators group. (Don't forget to disable the job when your done or you'll get the event log warnings that night [by the default schedule].)

    Of course, it would be nice if Microsoft would come up with a resolution to the crux of the problem (lol: or just get rid of the warning message altogether). From other's research, it sounds like this may be more deeply rooted than just SharePoint, though.

    jueves, 21 de junio de 2012 18:47
  • The issue is that users, unless the software is advertised, do not have rights to install software (which is what this process is attempting to do):

            internal static uint GetPropertyUsingProductCode(string prodCode, string propertyName, out string propertyValue)
            {
                SPMsiSafeHandle handle;
                propertyValue = "";
                IntPtr phWnd = new IntPtr(0);
                MsiSetInternalUI(2, out phWnd);
                uint num = MsiOpenProduct(prodCode, out handle);
    MsiOpenProduct is what generates the warning you see in the Application Event Log.
            [DllImport("msi.dll", CharSet=CharSet.Unicode)]
            internal static extern uint MsiOpenProduct(string szProduct, out SPMsiSafeHandle hProduct);

    The only way to allow a non-administrator to install software is to either publish it, or set the AllowElevatedInstallation = 1, which is a security issue as that would allow non-administrators to adjust sensitive hives and files.

    While you see the warning, the job succeeds (indeed, all the way -- turn on MSI verbose logging) so there is no real need to elevate your Farm Admin account to Local Admin (unless you're running the UPSS...).


    http://sharepoint.nauplius.net

    jueves, 21 de junio de 2012 18:53
    Moderador
  • Apologies Paul, I'd missed that you were running with the manual approach. I did read that long ago (I've been following this thread for some time) but lost track of it. Yeah, if I was administering a network I think I would go that way myself, absent a fix here. 
    jueves, 21 de junio de 2012 22:20
  • Hey Trevor. Thanks. I wasn't sure which method it was failing on although I understood it was the Windows Installer Service that was getting called by the job. There are three things that are still interesting to me though:

    1. The job succeeds anyway. How? Does it just continue to run the rest of its checks but fails on this one? If it doesn't fail on this one, why not? If it does fail here, but then continues, should we be concerned about the quality of the data in Manage Patch Status? 
    2. Or... does it somehow succeed once it uses the DCOM rights which appear to clear the 10016 errors? What I've never been able to reconcile with these warnings is that we've granted DCOM rights to launch and activate the Windows Installer Service and that definitely seems to make a difference to success or failure of the job - so why doesn't it clear these warnings? 
    3. Why does granting the file system permissions clear the FIM version of this job's warnings, but not for the Product Version Job? This is particularly vexing since granting the DCOM rights appears to resolve the 10016 errors in exactly the same manner for both jobs. 

    All of this has led me to believe that there were missing permissions somewhere, probably on the file system, but I just haven't had any luck pinning that down. One reason why I continued to pursue a solution to this is that the job doesn't actually try to install anything, it's just trying to use the Windows Installer Service to query the installed version, and the DCOM rights should be sufficient to invoke the service. But getting much further than this has proven pretty difficult since I'm not a dev and I've kind of pushed my limited reflection skills and understanding of the Windows Installer Service to the limit. If anyone can chip in and make some progress from this point, it'd be great to join forces! 

    jueves, 21 de junio de 2012 22:20
  • 1) Probably doesn't require the permissions we think it does, this will take a bit more investigating.

    2) I don't believe clearing the DCOM errors is a requirement, either (I'd need to re-check, though).

    3) Because the FIM warnings are going over the file system where Network Service doesn't have access, unlike the ProductVersionJob, which parses keys that the Farm Admin account does have access to (SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\14.0\WSS\InstalledProducts).

    At any rate, I've been taking a look at this since last night... and without elevating to administrator, or "publishing" the SharePoint msi's (not a great idea ;)), there is no way to make this work properly.  There is certainly no way to make this work securely, as you may as well just make the Farm Admin a Local Admin if you are going to grant the necessary rights to install an MSI as a non-Administrator.


    http://sharepoint.nauplius.net

    jueves, 21 de junio de 2012 23:18
    Moderador
  • I guess I'm still not seeing that we have to grant rights to install something per se, since this job will already have rights to use the Windows Installer Service to query once we've solved the DCOM 10016 errors, right? Or am I missing something there?

    I don't think we'd seriously look to solve these warnings until after solving the DCOM error, which actually stops the job from running. So the way I see it, whether we're happy with the rights to use the Windows Installer Service is a question that we should be asking when we decide whether or not to grant the DCOM rights. By the time we are focusing on these warning I would assume the farm account has the right to launch the service through DCOM, in exactly the same way as the NETWORK SERVICE does once we fix those FIM DCOM 10016 errors. This is why I still assumed that there was some further permission issues for the Farm account that were triggering these warnings. 

    viernes, 22 de junio de 2012 0:34
  • You have to grant the rights in order to connect to the MSI Server.

    The DCOM error doesn't prevent the service from completing the Product Versions Job, either.  Again, enable full MSI logging and you'll be able to see that the difference between Local Admin, no Local Admin + DCOM fix, no Local Admin and no DCOM fix is only about two lines.  In fact, these two lines appear when you run the Farm Admin as Local Administrator:

    MSI (c) (40:40) [18:03:31:866]: Cloaking enabled.
    MSI (c) (40:40) [18:03:31:866]: Attempting to enable all disabled privileges before calling Install on Server

    Farm Admin w/o Local Administrator:

    MSI (c) (8C:78) [17:54:02:880]: Failed to connect to server. Error: 0x80070005

    Nothing else is different.  


    http://sharepoint.nauplius.net

    viernes, 22 de junio de 2012 1:09
    Moderador
  • So in that case do you reckon the Product Version Job doesn't actually work properly (in terms of actually detecting the state of the installed components on a server) without administrative rights? And if so, what does granting the DCOM rights actually accomplish other than removing the 10016 errors? And it still isn't clear to me why the FIM Product Version job can succeed without admin rights when this one fails if this is all about the Windows Installer rights rather than the job itself. I must be missing something really obvious.


    --- http://twitter.com/tristanwatkins http://tristanwatkins.com

    viernes, 22 de junio de 2012 12:52
  • No, it seems to always work right, admin rights or not.  And yes, fixing the DCOM errors just seems to fix the DCOM errors.

    http://sharepoint.nauplius.net

    viernes, 22 de junio de 2012 13:03
    Moderador
  • Out of curiosity, how are you testing that the job works? You know that PSConfig and the installer both seem to call in to Microsoft.SharePoint.Administration.SPServerProductInfo.UpdateProductInfoInDatabase as well? 

    http://twitter.com/tristanwatkins http://tristanwatkins.com

    viernes, 22 de junio de 2012 13:40
  • You can turn on MSI verbose logging and it will produce the same logs, with the exception of the above lines, regardless if you have Local Admin or not.

    http://sharepoint.nauplius.net

    viernes, 22 de junio de 2012 14:05
    Moderador
  • That is a good way to view it, Tristan. They are indeed just warnings (annoying as they are to someone watching their event logs). If you're uncomfortable with the solution, just ignore the warnings: they aren't indicative of something that needs to be fixed. 

    I do use and understand the least privileged model, but I am comfortable with breaking that model for the 15 minutes it takes to add the farm account as an Administrator, reboot (not always necessary; but safest to do), run the "Product Version Job", and then remove the farm account from the Admistrators group. (Don't forget to disable the job when your done or you'll get the event log warnings that night [by the default schedule].)

    Of course, it would be nice if Microsoft would come up with a resolution to the crux of the problem (lol: or just get rid of the warning message altogether). From other's research, it sounds like this may be more deeply rooted than just SharePoint, though.

    I have come to the same conclusion. I also only add the Farm account to the Local Administrators group when needed - i.e. installing updates. My only comment is: Rather than reboot the server, just restart the SharePoint 2010 Timer service after adding or removing the Farm account to/from the Local Administrators group. This eliminates the 1015 errors in the Event Log. 

    For normal daily operations, I also create a custom view for Admintrator Events that filters out the 1015 Event IDs rather than disable the Product Version Job in the SharePoint Health Analyzer - just a personal preference so I don't have to remember to re-enable the job, and I can still see any real errors without the 1015 warnings cluttering the view.

    jueves, 02 de agosto de 2012 16:32
  • I have come to the same conclusion. I also only add the Farm account to the Local Administrators group 

    Where do I find the 'Local Administrators' group on a domain controller?

    Simon

    lunes, 06 de agosto de 2012 14:49
  • There is no concept of "local groups" on a DC.  Instead, use the domain group named Administrators.

    http://sharepoint.nauplius.net

    lunes, 06 de agosto de 2012 14:58
    Moderador
  • Received a message to check out http://support.microsoft.com/kb/2473430

    Article mentions folder  %programfiles%\Microsoft Office Servers\14.0, which isn't there on my server. Created it and followed the instructions, but it doesn't resolve the problem.

    Simon

    lunes, 07 de enero de 2013 8:37
  • Received a message to check out http://support.microsoft.com/kb/2473430

    Article mentions folder  %programfiles%\Microsoft Office Servers\14.0, which isn't there on my server. Created it and followed the instructions, but it doesn't resolve the problem.

    Simon

    I verified further up the thread that this does not work for the particular error this thread is about. Also, %programfiles% is an environment variable so you have to find wherever that resides on your server. also, if you're running SharePoint Foundation instead of SharePoint Server 2010, the location is different.
    lunes, 07 de enero de 2013 13:21
  • I've been getting the 1035 and 1015 events since the beginning of my 2010 installation and am still seeing them.  Has anyone had an official fix from Microsoft?  I'm leaning towards using the workaround that Paul E suggested, but just wanted to see if there are any updates. 

    Thanks!

    jueves, 11 de abril de 2013 15:30
  • So this is what I discovered with this problem. Add the Farm account to the local Admin group on the server.

    Then restart the timer service. Now pull the Farm account out of the local Admin group. Run the Product Version Job manually and you will notice that the 1015 Warning is now gone. Apparently, the Farm credentials are cached from the local Admin group and will eliminate the 1015 warning as well as the DCOM errors. This method will work until the server is re-booted or the Timer service is restarted again. This process works for me until Microsoft can permanaetly fix this issue.

    Thanks

    • Propuesto como respuesta SP-Jim miércoles, 24 de abril de 2013 16:28
    • Votado como útil SP-Jim miércoles, 24 de abril de 2013 16:29
    • Propuesto como respuesta SP-Jim jueves, 25 de abril de 2013 13:01
    miércoles, 24 de abril de 2013 16:28
  • SP-Jim: So, you leave your Farm credentials out there available to be used by any wayward Timer job? Brave.

    See earlier posts regarding recommendation from MS Premier Field Engineer (PFE).

    jueves, 25 de abril de 2013 16:18
  • I only use one account to act as the Farm service account and create separate accounts for each farm that I run.

    I pull the Farm account from the local Admin group after I restart the timer service. This allows the Product Version job to run without any error's and also allows me to not have to disable this job to run manually. I did set the schedule for this job to run weekly instead of nightly. I also disabled the Timer Recycle job as this would clear the Farm account from the timer service.

    Thanks

    jueves, 25 de abril de 2013 17:47
  • SP-Jim: REALLY!???!?? YIKES. I'm no MVP, but I have a hard time imagining any of them would back this "solution." Sure, it likely works, but I'm pretty sure it goes against a whole bunch of Best Practices.
    jueves, 25 de abril de 2013 19:27
  • Such as?? I'm still maintaining least-privilege by ensuring that the Farm account is not part of the local admin group and the Health analyzer is not barking about the Farm account being in the local admin group. The point is to ensure that the Product version job runs cleanly without DCOM or event viewer error's. Until Microsoft come up with a better solution.....
    jueves, 25 de abril de 2013 20:41
  • Well, SP-Jim, think about it: If the Product Version Job can use the Farm account with local admin permissions, what's to keep other timer jobs from doing the same?
    jueves, 02 de mayo de 2013 16:30
  • Much like the UPSS provisioning timer job, the Product Versions Job requires Local Administrator rights to function correctly.

    SharePoint - Nauplius Applications
    Microsoft SharePoint Server MVP
    MCITP: SharePoint Administrator 2010

    -----------------------
    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    jueves, 02 de mayo de 2013 16:32
    Moderador
  • PaulE, besides the UPS provisioning timer job as mentioned by Trevor, what other timer jobs require Local Administrator rights? The method I proposed allows you to run the Product Version job without having to re-boot the server. I could never condone re-booting a production server just for the sake of running the PV job.
    viernes, 03 de mayo de 2013 18:30
  • There should be no other jobs that require Local Administrator rights to function (but may require other group membership rights, like Performance Log Users/Monitors).

    SharePoint - Nauplius Applications
    Microsoft SharePoint Server MVP
    MCITP: SharePoint Administrator 2010

    -----------------------
    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    viernes, 03 de mayo de 2013 18:35
    Moderador
  • Looks like SP-Jim's been able to get the Product Version job to work without rebooting the machine and, instead, restarting the timer service. That's good news. I would highly recommend restarting the timer service after the job has ran and the Farm account has been removed from the Administrators group. Otherwise, what's to stop other timer jobs from using this elevation of priviledge to do something they shouldn't? Without restarting the timer service, the Farm account's admin rights still linger in the service and could be used by other timer jobs.

    martes, 07 de mayo de 2013 20:26
  • It is not just the timer service that needs to be restarted.  Rather, you need to examine all services leveraging your farm admin account.  If you have >1, then you'll need to stop all of them (Timer Service, could be CA Web App Pool, etc.), then once you've confirmed the account no longer appears in Task Manager, start the services back up.  This will complete the refresh of the user's group token.

    SharePoint - Nauplius Applications
    Microsoft SharePoint Server MVP
    MCITP: SharePoint Administrator 2010

    -----------------------
    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    martes, 07 de mayo de 2013 20:34
    Moderador
  • My Farm Service account is only used for Central Admin, UPSS and now the Product Version Job. I use separate accounts for Search, Service Applications and Web Apps in the same Farm. Each Farm that I manage has it's own unique set of accounts that are configured the same way. I have since just disabled the Product Version Job as this only needs to run when Sharepoint updates are applied. The process that I have described above will allow me to run this job when needed without having to re-boot which is critical in a production environment.
    miércoles, 08 de mayo de 2013 13:33
  • Hi Ali,

                  I have one issue in installing dot net frame work in windows Xp machine, it is installing but in the

    finishing time, it roll back everything and shows error.kindly help for this.

    Regards,

    Deva.

    martes, 09 de julio de 2013 8:22