Announcement

Collapse
No announcement yet.

Updating SP 2013 without interactive login

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Updating SP 2013 without interactive login

    Deploying SP versions is greatly simplified by tools such as AutoInstaller. But how can monthly updates (which now include CUs) be installed from WSUS without logging into the server? I've got a script assembled from various sources which works flawlessly as a scheduled task on all my servers except SP farm servers. In order to run either the script or just the WSUS process, I have to be logged in interactively to the affected servers. My script suspends and disables the search and user profile sync services as needed, and restarts the server when any of several reg keys are set for it. But each month the Sharepoint farm updates fail, and show as 'failed' in the WSUS console the next morning. I'm fully aware of the need to re-run the Conf Wizard following updates, but the idea is to run the farm updates in the wee hours without human involvement, so that running of the Wizard and the restart needed (if any) can take place as early as possible the next morning.

    I have not found a single resource on-line which answers this one question. Ideas?
    *RicklesP*
    MSCA (2003/XP), Security+, CCNA

    ** Remember: credit where credit is due, and reputation points as appropriate **

  • #2
    More info: running the scheduled update task works for every update in a monthly cycle, except those which are named as Sharepoint Farm updates. Makes no difference whether the 'farm' service account, or the domain 'God' account, is used to run the task. But if I interactively log in with either set of credentials and run the PS1 script manually, everything works perfectly. Still no takers?
    *RicklesP*
    MSCA (2003/XP), Security+, CCNA

    ** Remember: credit where credit is due, and reputation points as appropriate **

    Comment


    • #3
      The only thing i can think of is that the Run when the User logged in Checkbox is ticked.

      You've probably seen all these but might be worth having a look over

      https://community.spiceworks.com/how...task-scheduler

      IIRC i'm pretty sure i had an issue trying to get some powershell scripts running from a server and eventually gave up.

      Comment


      • #4
        Thanks, wullieb1, but running of the PS script isn't the issue. Check this out: my SP 'farm' is 2 servers: the web and core on 1 server (small user base), and SQL on another server. I also have a WSUS server in this domain. All 3 running 2008R2 in my domain, SP is v2013. If I have 3 updates approved for 2008R2 OS installs, and 2 SP farm updates, that means my SP server has a total of 5 updates pending. My PS script will run during the wee hours as planned, and all 3 OS updates install without incident. But the 2 farm updates will fail, and the error code is always 80070240. If I log onto the server with the same creds that the PS script was run under by the scheduled task, and I re-run the entire task, the farm updates install perfectly. Every time.

        All the searches I've done come back to simple issues with WSUS itself, as if assuming the error code applies to the update session itself as a whole, not to individual updates during that session. And here's another mind-bender: I have a development environment to test updates on, which duplicates my production system. And yes, the same behavior manifests for the same updates on both. The bender is that I also have a SP Foundation server in my Dev system for something, where everything is all on the one box. For SP updates, the same KB update articles are almost invariably published as separate SP updates for both types, and the Foundation updates don't give me this grief.

        I never seem to get the easy ones.
        *RicklesP*
        MSCA (2003/XP), Security+, CCNA

        ** Remember: credit where credit is due, and reputation points as appropriate **

        Comment


        • #5
          Ahh ok now i see. I've obviously read it wrong and ass-u-med that the script wasn't running at all but it is, it applies the normal OS updates but not the SP updates.

          80070240 is usually something to do with BITS but i would doubt there is an issue with that as the other updates are fine.

          Just as a test are you able to run the OS updates then stop and restart the BITS service before running the SP updates? Long shot but worth a try.

          Comment

          Working...
          X