How to force check in after a script completes that is running as logged-in user context?
We have a script that runs as the Logged-in user to adjust or add some regkeys in the Current_User key. The script runs as expected, but we now need the script to force a check-in once completed. Our staff are not admins and because its a Logged-in user script the command to launch the runkbot.exe 4 0 will not run because they do not have permissions. Is there another way to force the check in once this script completes? Any suggestions?
Answers (2)
You could run these as a task chain. The first task could be the script that runs as the current logged-in user, then the second task in the chain could be the script that runs inventory as the system user.
I suggest not to check in after a script for multiple reasons.
You can do multiple things to update the DB and depending on what you want only update partially.
As an example if you have Custom Inventory Rules which need to be updated (I think of a script which adds users or similar and you have CIR to track users) you could do this with
$(KACE_APP_DIR)/KDeploy -custominventory
But the main question:
You can create a script as System Service and link the script you want to run and the script to update the DB in a Task Chain
You use a rights evlevation in the script. https://social.technet.microsoft.com/Forums/scriptcenter/en-US/e75b24fb-bb46-480a-9d12-2494d80697cb/how-do-i-make-a-script-quotrun-as-administratorquot-on-its-own is a good example and start for thinking of the process aside of the classic "runas"
Comments:
-
Thanks guys - I am not familiar with a task chain. Had to look it up and still not sure I fully understand how this would work for the scenario I am looking at. Perhaps I should list of some additional information on what we are doing.
Please note, my scripting knowledge is limited and I am sure there are many ways to accomplish this task by the method below has worked well for us over the years.
First off, we are running 2 separate scripts to upgrade MS Office 2016 from 32 bit to 64 bit. in addition, we are also removing and then replacing our custom Word Macros files and regkeys. Lots of nuances with this install but wont go into to much details.
As a result, we have areas where we need to run somethings as the system account and others as the logged-in user. Good news is once we get through this upgrade for our staff, managing these going forward will be much easier as we are now moving things to the ProgramData and HKCU area that staff can modify with out admin rights. But out previous was created when all staff where local admins.
Script 1:
The first set of tasks runs in a script that the staff kick off them selves on-demand from the Users Download area to install the Office upgrade script (script 1) when ready. This script runs as the System account and performs the following:
-Deletes old custom Macro RegKeys (in HKLM)
-Deletes old custom macros files (stored in Programs Files (X86))
-Perform the MS Office upgrade to 64 bit
-Adds new custom Macro Files to C:\ProgramData
-Adds new custom RegKeys about this script to HKLM that the install is complete (along with some details that Script 2 looks for).
-Runs a Kace check in (so the steps above gets register). runkbot.exe 4 0
We then have a CIR that checks for this key and adds it to a custom Label.
Script 2:
We then have a 2nd script (scheduled to run every 5 minutes) that applies only to the machines in the above custom label and runs as the Logged-in user and makes the following changes:
-UpZips a large .reg file with the new custom regeky keys for the macros to operate into HKCU
-Runs the Import .reg key command
-It then modifies the custom regkey added at the end of script 1 to change the value that the CIR is looking for (from No to Yes) which would remove it from the label and no longer receive the 2nd script.
The last step however, was to force the check in again so the above works and its removes quickly, but that's where we have the issue due to how script 2 is running as logged in user and the force check in command don't work.
We have other scripts that work similarly and its been great. Just never used a 2nd script that is running as a logged in user before.
Not sure if this helps or not, but if you do have any suggestion to get this 2nd script to force check in, we would be good to go. - mjrichardson 3 years ago
Please note, my scripting knowledge is limited and I am sure there are many ways to accomplish this task by the method below has worked well for us over the years.
First off, we are running 2 separate scripts to upgrade MS Office 2016 from 32 bit to 64 bit. in addition, we are also removing and then replacing our custom Word Macros files and regkeys. Lots of nuances with this install but wont go into to much details.
As a result, we have areas where we need to run somethings as the system account and others as the logged-in user. Good news is once we get through this upgrade for our staff, managing these going forward will be much easier as we are now moving things to the ProgramData and HKCU area that staff can modify with out admin rights. But out previous was created when all staff where local admins.
Script 1:
The first set of tasks runs in a script that the staff kick off them selves on-demand from the Users Download area to install the Office upgrade script (script 1) when ready. This script runs as the System account and performs the following:
-Deletes old custom Macro RegKeys (in HKLM)
-Deletes old custom macros files (stored in Programs Files (X86))
-Perform the MS Office upgrade to 64 bit
-Adds new custom Macro Files to C:\ProgramData
-Adds new custom RegKeys about this script to HKLM that the install is complete (along with some details that Script 2 looks for).
-Runs a Kace check in (so the steps above gets register). runkbot.exe 4 0
We then have a CIR that checks for this key and adds it to a custom Label.
Script 2:
We then have a 2nd script (scheduled to run every 5 minutes) that applies only to the machines in the above custom label and runs as the Logged-in user and makes the following changes:
-UpZips a large .reg file with the new custom regeky keys for the macros to operate into HKCU
-Runs the Import .reg key command
-It then modifies the custom regkey added at the end of script 1 to change the value that the CIR is looking for (from No to Yes) which would remove it from the label and no longer receive the 2nd script.
The last step however, was to force the check in again so the above works and its removes quickly, but that's where we have the issue due to how script 2 is running as logged in user and the force check in command don't work.
We have other scripts that work similarly and its been great. Just never used a 2nd script that is running as a logged in user before.
Not sure if this helps or not, but if you do have any suggestion to get this 2nd script to force check in, we would be good to go. - mjrichardson 3 years ago