Temporary Write Permission for a Drive / Logging off and Logging in.

No shutdown needed, just a logoff.
If you would like to have a way that does not need a logoff: there is. Try (as user) the command
klist purge

I can try klist purge.
In my ignorance, I was trying to avoid a scheduled logON - thus the restart because I know how to do that!  :-)
But this sounds better....

I already have a .bat file to change the Group membership
I suppose I could add this line to that file.

So:
There is a scheduled task to run a .bat by an Administrator user with:

net localgroup WRITE_Backup Backer /add
net localgroup READ_ONLY    Backer /delete

Select allOpen in new window

Followed by a scheduled task to run a .bat run by the current user with:

klist purge

Select allOpen in new window

Presumably the latter doesn't require administrative privileges nor any other interaction?

klist purge is not asking the user anything and does not need admin privs. However, it is only useful in an environment where Kerberos authentication is in use. If, and i can see that by looking at your script, you don't use a domain, you won't even use Kerberos and klist purge is useless. You should rather just use the command logoff.exe to log off the user.

OK.  That gets me that far then.  Thanks!
How would you recommend that I follow logoff.exe with a logon for [User]?
The User is a standard user and, it appears, must be logged on for its scheduled tasks to run.
I've tried running the task whether the user is logged in or not but it seems to not work for a non-Administrator user.

Help me with your logic: you would like a group change. You do this group change using a scheduled task.
Who starts that task? the user himself?
Why change the group? To enable him to write somewhere for a limited period of time?
Just short answers needed. I will recommend a solution, then, that might be easier.

The reason for a group membership change is to avoid having to propagate permissions on a large drive.  And, yes, to allow a short time to write.
It works great!
An administrator starts the task whether logged in or not.

At this stage I'm not sure that a group change done this way requires a reboot or a logoff/logon.
But I'm doing it with a reboot nicely enough.

Thanks!

It does require a logoff and logon again - no reboot.
Why would someone be granted write permissions for a limited time, what's the use? To prevent what? (just trying to help :-)

If a drive has no WRITE permissions then it can't be encrypted by ransomware.  If it has WRITE permissions in a narrow window of time - at well-selected times of day -  then the likelihood of nefarious WRITEs is reduced.

If I knew how to schedule both log on as well as log off then I'd not have to reboot.  But the reboot is pretty easy to do and accomplishes the same thing.

To keep ransomware from encrypting that drive, simply use a different account for backups and entitle only that account to write to that backup folder. No need for that procedure of group changing.

What do you mean "a different account"?
I have an account for this purpose.
It's a standard user account / not administrator.
The backup tasks are scheduled using the Windows Task Scheduler for that user.
But the user has to be logged on for the tasks to run.
Using "run whether the user is logged on or not" doesn't seem to work for this user.  
I *am* using an administrator user to switch the groups - not logged on.

So, I've done exactly what you've suggested I believe.  I set up an account for backups (I just wouldn't call it "different") and entitled only that account to write to the backup folder.
Further, I'm limiting the times when that writing is permitted.
Perhaps the only difference is that this user has to be logged on during the writing in order to schedule the writing.

Let the system account run the task. The thought to give time limited access is not that good. The system account can backup everything and malware executed by the user cannot touch the backups, then

So you are suggesting that the SYSTEM account is somehow invulnerable?  I don't doubt it but it's beyond my knowledge and/or understanding.

So I could change the scheduled tasks to be run by SYSTEM.
And SYSTEM would have WRITE permission on the backup drive.

How is that different?  I'm not suggesting it isn't different;  I'd just like to understand better.

Instead of modifying what a user may do, you change to a different user that may already do anything (namely the system account). Malware that the user executes acts as that very user. If we work with an account that cannot access the backup, neither will any malware that we execute be able to access the backup.

If we work with an account that cannot access the backup, neither will any malware that we execute be able to access the backup.

??? We need to be working with an account that can write to the backup.  So this confuses me.

You have an account to do your work with and another another account to create backups. The latter is the system account. The former account should not be enabled to access the backups, only the system account should do that.

McKnife:  The framework is a little different.  But now I understand what you meant.  Thanks!  

The computer is a headless background workstation that does backups.  So there is no "to do your work" situation at all.
So back to 42200670.

Reducing the time for ransomware is what you want, so be it. You will succeed with your reboot command, why not.

Yes.  But I was intrigued by your suggestion that it could be done with user:SYSTEM and was hoping to confirm.
Even that could be time-window-limited. But I get the impression from you that it might not be necessary for this case. (?)

Windows Task Scheduler
Task run by SYSTEM.
It comes up "Run only when user is logged on" and is grayed out.  So I guess that's implied for SYSTEM.
Permissions on backup store are needed for SYSTEM anyway.
Share permissions for READ are still needed for others who never log on to this machine / just share access.

OK.  Thanks!!

The task scheduler fires off OK using SYSTEM, not logged in, Highest privileges, Windows 10.
The batch file it launches, does launch.
The .exe file the batch launches does not.

When a different account launches scheduler, you will not see what it executes (no visible windows). Task manager will show the processes, though. Did you check in task manager? If it does not appear in there, could it be that your .exe is not accessible by the system account (as in: on a network share)? If so, launch it using the UNC path instead: \\server\share\some.exe