Can action continue after shutdown

Content Authoring
1

Hi

Is it possible for an action to continue after the computer has had an (unexpected) shutdown?

Thanks!

2

If the computer rebooted mid-action then that particular action would fail if the action needed to run all lines (default for tasks) or the success relevance hadn’t been met (default for fixlets).

3

and no possible work around?

4

What is your use case?

5

Well:

I have an action that makes a user local admin. After 4h (but in the same action, with a pause statement for 4h), the local admin will be deleted again.

The problem is, when they shutdown/reboot their computer, the action fails, but the user is still local admin…

here is my code:

// Enter your action script here

// Parameter Logged on user
parameter "LoggedOnUser" = "{name of current user}"


// Make local admin
dos net localgroup Administrators {parameter "LoggedOnUser"} /ADD



// Disable wow64 redirection on x64 OSes + logoff
action uses wow64 redirection {not x64 of operating system}
override wait
   runas=currentuser
wait logoff {session id of current user}


// Wait x time
parameter "start" = "{now}"
pause while {now < ( ((  parameter "start" of action  ) as time ) + 4* hour)}


// Delete local admin
dos net localgroup Administrators {parameter "LoggedOnUser"} /DELETE


// Disable wow64 redirection on x64 OSes + logoff
action uses wow64 redirection {not x64 of operating system}

override wait
   runas=currentuser
wait logoff {session id of current user}

Any idea how I can overcome that?

Thanks for answering!

6

The best idea I have would be to use a client setting to record when it was changed and split it into two actions so you don’t have to pause. Make your first action this:

// Parameter Logged on user
parameter "LoggedOnUser" = "{name of current user}"

//Logging the name of the user in case they are not logged on when the removal fix is run
setting "AdminName"="{name of current user}" on {now} for client

// Make local admin
dos net localgroup Administrators {parameter "LoggedOnUser"} /ADD
    
// Disable wow64 redirection on x64 OSes + logoff
action uses wow64 redirection {not x64 of operating system}
override wait
   runas=currentuser
wait logoff {session id of current user}

// Wait x time
setting "AdminTimer"="{now}" on "{now}" for client

Your second task would have a relevance looking at the time of the “AdminTimer” client setting and doing the math.

now > (effective date of setting "AdminTimer" of client) + 4* hour

Then have it do the other half of the action.

//If a user is logged in, perform the following action
if {exists name of current user}

// Parameter Logged on user
parameter "LoggedOnUser" = "{name of current user}"

// Delete local admin
dos net localgroup Administrators {parameter "LoggedOnUser"} /DELETE

// Disable wow64 redirection on x64 OSes + logoff
action uses wow64 redirection {not x64 of operating system}

override wait
   runas=currentuser
wait logoff {session id of current user}

//Delete the AdminTimer setting and AdminName settings
setting delete "AdminTimer" on {now} for client
setting delete "AdminName" on {now} for client

//If there is no current user, do this
elseif {exists setting "AdminName"}

// Delete local admin
dos net localgroup Administrators {setting "AdminName" of client as string} /DELETE

//Delete the AdminTimer setting and AdminName settings
setting delete "AdminTimer" on {now} for client
setting delete "AdminName" on {now} for client

endif

The beauty of this is you can make the second action a policy action that applies wherever it’s applicable indefinitely.

EDIT:

One other thing you might want to keep in mind is if the user previously invoked is no longer logged onto the machine. I would also do a client setting invoking their name in case no one is logged into the machine at the time this is run. I’ve incorporated them into the above scripts with annotations.

4 Likes
7

Hi,

Thanks for the great answer, it is really useful. The setting “AdminName” i’ll definitely use that. I thought about it (that’s why I use the parameter in the beginning) that this could be useful. But what is the difference between setting & parameter?

For splitting up the action: the problem is that it’s not possible. It can only be 1 action (management decision), because the user can go offline. When he’s offline, the client can’t evaluate the 2nd action. So our security team will have problems with that.

So any idea how to fix that…?
So basically I need an action that continues to run, even when the computer has had a shutdown/reboot or when the computer is offline… (I know, not an easy task…)

I really appreciate your help!

8

If you have the policy action open, it should correct the non-compliant user even if the computer is not on the network. You won’t see the status of the action until it comes back on the network but the action should run regardless.

The action would be part of the action site the client received when it last gathered new content and that would include the fixlet giving the user admin and the fixlet removing that admin access and logging them out after 4 hours.

1 Like
9

Hi jmaple

I tried it with the setting, but it fails:

failed.PNG815Ă—125 3.92 KB

Any idea why?

Thanks!

10

Goofed on that.

setting "AdminName"="{name of current user}" on {now} for client
1 Like
11

If you want to restart mid-action and resume afterwards, I suggest a putting your before and after reboot items into separate tasks and insert them into a small baseline.

The key to make this work is to use the actionscript command to restart. If you use an OS command or allow the user to restart ad hoc, it will fail.

So the end of the pre-reboot task would end like so:

action requires restart
restart 60

The beginning of the second task would include:

pause while {pending restart}

This keeps the client from rushing ahead into the rest of the script.

12

FYI, my 2 actions:

1st:

// Enter your action script here

// Parameter Logged on user
parameter "LoggedOnUser" = "{name of current user}"


// Make local admin
dos net localgroup Administrators {parameter "LoggedOnUser"} /ADD


//create registry entries
action uses wow64 redirection false

delete __createfile
delete wizardedit.reg

createfile until @end_create_reg_file
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\YPTO\LOCALADMIN]
"Name"= "{name of current user}"
"Date"= "{now}"
"DateEnd"= "{now + 4*hour}"
@end_create_reg_file

move __createfile wizardedit.reg
waithidden regedit /s "wizardedit.reg"


// Disable wow64 redirection on x64 OSes + logoff
action uses wow64 redirection {not x64 of operating system}
override wait
   runas=currentuser
wait logoff {session id of current user}

2nd, which is an open action that reapplies whenever it becomes relevant:

Relevance:

((last 4 of first 16 of it & " " & last 3 of first 11 of it & " " & last 2 of first 7 of it & " " & last 8 of first 25 of it) of (value "DateEnd" of key "HKEY_LOCAL_MACHINE\SOFTWARE\YPTO\LOCALADMIN" of native registry as string)) < (last 4 
of first 16 of it & " " & last 3 of first 11 of it & " " & last 2 of first 7 of it & " " & last 8 of first 25 of it) of (now as string)

Action script:

// Parameter Logged on user
parameter "AdminUser" = "{(value "Name" of key "HKEY_LOCAL_MACHINE\SOFTWARE\YPTO\LOCALADMIN" of native registry as string)}"

// Delete local admin
dos net localgroup Administrators {parameter "AdminUser"} /DELETE


action uses wow64 redirection false

delete __createfile
delete wizardedit.reg

createfile until @end_create_reg_file
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\YPTO\LOCALADMIN]
"Name"=-
"Date"=-
"DateEnd"=-

@end_create_reg_file

move __createfile wizardedit.reg
waithidden regedit /s "wizardedit.reg"



//if user is logged on
if {name of current user as lowercase equals parameter "AdminUser" as lowercase} 
// Disable wow64 redirection on x64 OSes + logoff
action uses wow64 redirection {not x64 of operating system}

override wait
   runas=currentuser
wait logoff {session id of current user}

If somebody needs more information about, feel free to ask.