Jump to content


Christian Silvert

Established Members
  • Content Count

    13
  • Joined

  • Last visited

  • Days Won

    1

Christian Silvert last won the day on April 13 2018

Christian Silvert had the most liked content!

Community Reputation

1 Neutral

About Christian Silvert

  • Rank
    Member
  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): Non-working (no standard user permissions): 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. 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. 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
  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. Here you have the zip file. Yes, once a day @ 11 am. But this time I launched it manually while testing it. Regards, Christian Windows10RequiredUpgradeStart-Upgrade.zip
  7. 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
  8. 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
  9. Wow, it works now! After I added the line that you suggested! <meta http-equiv="Content-Type" content="text/html;charset=utf-8"/> Thanks alot! :=)
×
×
  • Create New...