Jump to content


Christian Silvert

Established Members
  • Posts

    13
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Christian Silvert

  1. Yes, it is a strange behaviour!

    The Copy Content in this package... was already checked. 

    The difference I see between a working client and a non-working is this: 

    Working (the standard user has Full Control to the folder for some reason): 

    image.png.f3aaa44593a45a4dc0d8683dbd035711.png

     

    Non-working (no standard user permissions): 

    image.png.28745decd2ac3ca91a776e8509fcf810.png

    Have you tested the permission difference for the ccmcache folder in your lab?  Notice that the package is pre-downloaded to the cache with a prestage TS. Maybe that can cause problems?

    Thanks!

    Regards, Christian 

     

  2. 1 hour ago, Christian Silvert said:

    The HTA package is prestaged in a Task Sequence (with a Download Package Content step). So the package is already in the ccmcache when the actual upgrade Task Sequence tries to run the script.

    //Christian 

    Hi again!

    When we add the user account with full control permissions on the ccmcache folder, it works. So it is a permission error. How can we solve this? Is there a reason why the script needs to run with user rights? 

  3. 14 minutes ago, Christian Silvert said:

    Hi!

    We're having some problems with the start-upgrade.ps1 script in a customers environment. The Task Sequence cannot start this script because of a access denied error (see attached file). The users are not local admins. I'm wondering if local admin rights is a prereq, because the program runs with User Rights? When I login with a user account with local admin rights, it works fine.

    Se attached file with error message from execmgr.log

    //Christian

    execmgr_log.jpg

    The HTA package is prestaged in a Task Sequence (with a Download Package Content step). So the package is already in the ccmcache when the actual upgrade Task Sequence tries to run the script.

    //Christian 

  4. Hi!

    We're having some problems with the start-upgrade.ps1 script in a customers environment. The Task Sequence cannot start this script because of a access denied error (see attached file). The users are not local admins. I'm wondering if local admin rights is a prereq, because the program runs with User Rights? When I login with a user account with local admin rights, it works fine.

    Se attached file with error message from execmgr.log

    //Christian

    execmgr_log.jpg

  5. I understand where you are going. The thing is that I started the wrapper manually at 12:42 and the upgrade was finished at 14:11 and it returned Exit code 0 to config mgr as successfully completed.  Here comes the strange behavior: then I logged on the computer to check things. Shortly after logging in , the wrapper seemed to launch automatically in the background at 14:13 without me knowing it and returned Exit code 99 to config mgr. I understand that this wrapper launch should not be happening until 11 AM next day (If it's still in the collection)

    I will have to run some more tests to see if this behavior is consistent :)

     

     

  6. Hi Niall!

    I think the wrapper launched by itself very quickly after the upgrade (I thought this was only occuring at the scheduled time once a day?), so it reported code 99 before the computer had falled out of the collection. I have excluded the collection with the desired build with a frequency of every hour. So I'm not sure why the wrapper auto-launched so quick after the upgrade?

     

    //Christian

  7. Hi Niall!

    I just performed an In Place Upgrade with success. When the task sequence succesfully ended and the computer reported version 10.0.16299 (as the target build number specified), the wrapper sent exit code 99 to Config Mgr because of the target build check. However, this is wrongfully shown as an error in the task sequence deployment in Config Mgr. Is this per design? Or am I missing anything? 

    Regards, Christian

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.