none
Script at Shutdown : GPedit.msc OK, with script (reg import) Failed RRS feed

  • General discussion

  • Hello,

    On Windows 7 Pro 64 bits,

    I try to build a script_B to be executed at Shutdown. with local Policy without AD.

    With GPedit.msc, the script_B at shutdown is executed with success.

    With a script_A, using the command "reg import", the script_B is not executed at shutdown and there is no trace of defect or error, and no log.
    When I check the registry, eveything is done on 64 bits and 32 bits parts both (wow6432node).
     
    --
    Contents of the REG file :
    ----------------------------------------------------------------------------------------------

    Windows Registry Editor Version 5.00   

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Scripts]   

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Scripts\Shutdown]   

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Scripts\Shutdown\0]   
    "GPO-ID"="LocalGPO"   
    "SOM-ID"="Local"   
    "FileSysPath"="C:\\Windows\\System32\\GroupPolicy\\Machine"   
    "DisplayName"="Stratégie de groupe locale"   
    "GPOName"="Stratégie de groupe locale"   

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Scripts\Shutdown\0\0]   
    "Script"="c:\\windows\\system32\\cmd /C C:\\script_B.CMD"   
    "Parameters"=""   
    "ExecTime"=hex(b):00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00   

    ------------------------------------------------------------------------------------------------


    Thursday, February 25, 2016 5:43 PM

All replies

  • Hello,

    How to disabled UAC without restart ?
    using :
    "reg ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f"

    Regards,

    Tuesday, January 26, 2016 1:55 PM
  • I check :

    https://social.technet.microsoft.com/Forums/windows/en-US/12eb6712-7713-4453-9c76-bba5a982ed0a/disable-or-quiet-uac-without-reboot-from-command-line?forum=itprovistasecurity

    https://social.technet.microsoft.com/Forums/scriptcenter/en-US/dba7daed-334c-4014-ada4-b1c882731445/disable-uac-completely?forum=winserverGP

    https://social.technet.microsoft.com/Forums/scriptcenter/en-US/30eb6ae0-b757-4c6e-8264-48dabe3c39ce/uac-elevate-without-prompting-does-it-really-disable-all-uac-?forum=w7itprogeneral

    ....

    Tuesday, January 26, 2016 1:58 PM
  • You should not disable UAC.

    You cannot disable UAC without a restart.


    -- Bill Stewart [Bill_Stewart]

    Tuesday, January 26, 2016 2:01 PM
    Moderator
  • Hello,

    "You should not disable UAC."

    On Windows XP, UAC didn't exist, and we live without it during many years.
    On Windows Seven, UAC exist and provide to many strange things...
    Can you explain indetails why I don't have to disable it temporarly, during a script execution ?

    --

    Then if it's not possible to disable UAC without restart,
    How to "elevate" all the activies done by user ? (system account) ?

    Regards,



    • Edited by Cerkyr Tuesday, January 26, 2016 3:09 PM
    Tuesday, January 26, 2016 3:05 PM
  • Right at the top of this forum, please read the following:

    You cannot bypass the UAC prompt

    You cannot bypass the elevation prompt, and this is by design.


    -- Bill Stewart [Bill_Stewart]

    Tuesday, January 26, 2016 3:10 PM
    Moderator
  • Hello,

    The goal is not to bypass the UAC prompt.
    The goal is to allow the SYSTEM account inside a script to do everything.
    EVERYTHING = all the available commands are allowed.
    And to do that, I suppose that disable UAC at the beginning of the script is the way to allow the SYSTEM account to do everything.
    But the computer need to be restarted to do disable UAC...
    Why the SYSTEM can't do everything on Windows 7 ?
    I can't delete a file here :
    "C:\WINDOWS\system32\GroupPolicy\Machine\Scripts\Shutdown"

    Regards,

    Thursday, January 28, 2016 8:35 AM
  • Hello,

    How to elevate a command ?
    How to be sure that every command lines are elevated through every accounts inside the Administrators local group and also for the SYSTEM account ?
    The computer is NOT inside a Active Directory, then no GPO ...etc.
    Then no UAC prompt.
    Then no blocking point.
    Then, the command lines are executed by a REAL administrator.
    Of course, the command lines are done through scripts (BATCH, VBS and POWERSHELL).

    Regards,

    Thursday, January 28, 2016 10:46 AM
  • We have no idea what you are trying to ask. Are you asking how to run an elevated process?  Right click on program and select "Run As Administrator".

    Please read the following: https://social.technet.microsoft.com/Forums/en-US/21afa490-a74e-4052-8c34-e997cdc593b3/you-cannot-bypass-the-uac-prompt?forum=ITCG


    \_(ツ)_/

    Thursday, January 28, 2016 10:53 AM
  • Hello,

    On Windows Seven 7 :

    My need is to :
    + Run scripts (with command lines) (VBS, batch powershel : depends on the need)
    + Executed by a account inside the Administrators group and also SYSTEM account.
    + All the command lines must be allowed, with no restriction, like UAC or something like that ...
    --
    Please, the goal is not to bypass UAC for everyone, but it's to run all the command lines by the Administrators with no blocking point.

    A administrator don't have to be in the loop of UAC.
    UAC is for users, not Admins.
    --

    Is it more clear ?


    • Edited by Cerkyr Thursday, January 28, 2016 11:09 AM
    Thursday, January 28, 2016 11:07 AM
  • Hi Cerkyr,

    you can create a scheduled task that runs commands or scripts with elevation without UAC prompts. You can key tasks to trigger upon events written to the eventlog and writing to the EventLog is something all locally connected users can do.

    This way you can prepare a specific action and allow other users to run it.

    Cheers,
    Fred


    There's no place like 127.0.0.1

    Thursday, January 28, 2016 11:13 AM
  • Hello,

    On Windows Seven 7 :

    My need is to :
    + Run scripts (with command lines) (VBS, batch powershel : depends on the need)
    + Executed by a account inside the Administrators group and also SYSTEM account.
    + All the command lines must be allowed, with no restriction, like UAC or something like that ...
    --
    Please, the goal is not to bypass UAC for everyone, but it's to run all the command lines by the Administrators with no blocking point.

    A administrator don't have to be in the loop of UAC.
    UAC is for users, not Admins.
    --

    Is it more clear ?


    Sorry but this is not possible in Windows.


    \_(ツ)_/

    Thursday, January 28, 2016 11:41 AM
  • "Sorry but this is not possible in Windows."
    Then, UAC must be disabled to allow the Administrators to do what they need ?

    Thursday, January 28, 2016 12:08 PM
  • "Sorry but this is not possible in Windows."
    Then, UAC must be disabled to allow the Administrators to do what they need ?


    You shoud NOT disable UAC for obvious reasons.

    \_(ツ)_/

    Thursday, January 28, 2016 12:22 PM
  • I would add that rephrasing the question will not get you a different answer.

    You cannot bypass the UAC prompt, and this is by design.

    There are system management tools available, such as SCCM, that run as SYSTEM that allow you to make changes on machines. Group Policy can also do this. But this is not the right forum to ask about SCCM or Group Policy.


    -- Bill Stewart [Bill_Stewart]

    Thursday, January 28, 2016 2:34 PM
    Moderator
  • Yes, the perimter is a script run by the SYSTEM account that can't delete a file and copy a new file with no clear explanation .

    Is it UAC ?
    Is it something else ?

    If I do the same activity on Windows XP, I have no problem, with the same script, and the same account SYSTEM.

    Then the design of Windows Seven are the search way  :
    + bypass the problem
    + fix the problem

    What is the right way ?
      # Is it bypass and bypass UAC or something else ?
      # Is it fix the problem and disable UAC or something else ?


    Friday, January 29, 2016 1:58 PM
  • You have a Windows security rather than a scripting question.

    Here's a better place to re-post your question:

    https://social.technet.microsoft.com/Forums/windowsserver/en-US/home?forum=winserversecurity


    -- Bill Stewart [Bill_Stewart]

    Friday, January 29, 2016 3:08 PM
    Moderator
  • Hello,

    Yes, after multiple different scripts, on different kind of Windows Seven (from Microsoft, from many LocalGPO),
    yes, we can say that our Windows Seven configuration seems to have a problem.
    --

    Yes, I open an issue related with security :
    https://social.technet.microsoft.com/Forums/windowsserver/en-US/60c3c673-ec81-4fd5-8b48-04a7098bdd74/elevate-a-command-by-script?forum=winserversecurity

    Thursday, February 4, 2016 3:47 PM
  • Yes, I open an issue related with security :

    Keep in mind that these are peer-to-peer support forums with no SLA. There's no guarantee of an answer, or, if you get an answer, that you will like the answer.


    -- Bill Stewart [Bill_Stewart]

    Friday, February 5, 2016 6:13 PM
    Moderator
  • you can start process as administrator from your script:

    It is possible to right click Powershell.exe (or it's Start menu shortcut) and run it As Admin.
    Shortcuts can be edited to always run as Admin - Properties | Shortcut | Advanced then tick "Run as administrator".

    To elevate a script from a (non-elevated) PowerShell command line :

    PS C:\> Start-Process powershell -ArgumentList '-noprofile -file MyScript.ps1' -verb RunAs

    A set of commands can also be saved in a scriptblock variable, and then passed to a new (elevated) PowerShell session:

    Start-Process -FilePath powershell.exe -ArgumentList $code -verb RunAs -WorkingDirectory C:

    To run an entire PowerShell session 'As Admin' from an existing PowerShell (non-elevated) session:

    PS> Start-Process powershell.exe -Verb runAs

    http://ss64.com/ps/syntax-elevate.html


    my blog: http://shserg.ru/

    Monday, February 8, 2016 3:22 PM
  • Correct; but you cannot bypass the UAC elevation prompt, which is the core of this question.


    -- Bill Stewart [Bill_Stewart]

    Monday, February 8, 2016 4:28 PM
    Moderator
  • Hello,
    How to manage the GPEDIT.msc activites inside batch script on a Windows Seven 7 64 bits ?
    Activities are : build a script to be run at shutdown.
    Regards,

    Wednesday, February 17, 2016 5:15 PM
  • To vague, no answer.

    Do you need help to locate were to add the policy in gpedit?

    Do you need help writing a script for a certain function?

    Do you want to be a millionaire?

    Do you want a hug?

    Are you in pain right now?

    Wednesday, February 17, 2016 5:19 PM
  • Hello,

    Registry "Wow6432Node" : is it for 32 or 64 bits session ?

    Regards,

    Wednesday, February 17, 2016 5:48 PM
  • 32.

    Wednesday, February 17, 2016 5:53 PM
  • Reads and writes from 32 bits go to the Wow.  YOU should not access this key directly from 32 bit sessions:

    https://msdn.microsoft.com/en-us/library/windows/desktop/aa384129(v=vs.85).aspx


    \_(ツ)_/

    Wednesday, February 17, 2016 6:14 PM
  • Hello,

    WOW64 = Windows 32 Over Windows 64

    Then, it means that an "application 32 bits" (APPL_32) will write new keys or data inside the registry, inside the "Wow6432node"

    Then, after that, what happen if the Windows Seven 64 bits (OS) (W7_64) will try to read the keys or data inside the registry ?
    W7_64 will try to read outside the "Wow6432node" ?
    W7_64 will not try to read inside the "Wow6432node" ?

    These questions are related with Local GPO (scripts at shutdown).

    --
    APPL_32 >> write in registry to run script at shutdown >> OS W7_64 at shutdown read the registry in or outside "Wow6432node" ?

    --

    Regards,

    Thursday, February 18, 2016 10:45 AM
  • Your question is not clear from what you posted. It does not appear to have anything to do with scripting.


    -- Bill Stewart [Bill_Stewart]

    Thursday, February 18, 2016 3:07 PM
    Moderator
  • 64 bit applications will never look at the WOW6432node, and they should never need to.

    Richard Mueller - MVP Enterprise Mobility (Identity and Access)

    Thursday, February 18, 2016 5:41 PM
    Moderator
  • Hello,
    For a executable file, there is a check box , in the "Compatible Mode" properties, related to "level of privilege". (the goal is to run the exec file as Administrator)
    How to check this box through a script (batch) ?
    Regards,


    Friday, February 19, 2016 9:53 AM
  • Create a shortcut and set the properties to "RunAs"

    http://poshcode.org/2513


    \_(ツ)_/

    Friday, February 19, 2016 10:02 AM
  • Hello,
    The goal is to check the box through a script, inside the properties "Level of Privilege ".
    The goal is not to create a shortcut through a script.
    Can you explain your proposal, with détails, step by step, and provide a link without any explanations ?
    Regards,
    Friday, February 19, 2016 10:27 AM
  • Hello,

    On Windows Seven 7 64 bits Pro, what are the new names of these 2 events ?

     WM_ENDSESSION

     WM_QUERY_ENDSESSION

    They was usefull on Windows XP, to intercept the shutdown.

    Regards,


    Friday, February 19, 2016 10:43 AM
  • Same names.  Those are not events.  They are windows message names from "windows.h". They are integer values used in the message dispatch system.  How they appear t a program depends on the subsystem and language.

    In VB.Net I believe they are OnEndSession and OnQueryEndSession.


    \_(ツ)_/

    Friday, February 19, 2016 11:14 AM
  • Hello,
    I use Windows Seven Pro 64 bits.
    --
    To control my activities in details , I use Process Explorer (from SysInternals) (32 and 64 bits).
    The tools is usefull.
    --
    I build a script and I try to run it on 64 bits mode, with SYSTEM account, using "%SystemRoot%\sysnative".
    But Process Explorer explain to me that the script is running in 32 bits mode.
    And a part of the script is to display a HTA file.
    Process Explorer show me the command line and the process mshta running for this HTA file.
    The command is good.
    --
    If I try to execute the same command with the local Administrator account, with "Run As", the HTA is displayed.
    Then, my scipt si very good.
    I don't make any error.
    The problem is Windows Seven 64 bits that doesn't show the HTA file .
    If I try the same script on Windows XP, I have no problem.
    Why ? (I need an example to understand your proposal)

    The other parts of the script are running without any problem.
    Only HTA is not displayed but it runs.

    Regards,


    Monday, February 22, 2016 5:02 PM
  • Start your script from a 64 bit session.  You are starting it from a 32 bit session.  Once in  32 bit session you cannot access the 64 bit environment.


    \_(ツ)_/

    Monday, February 22, 2016 5:10 PM
  • Same answer as a previous thread you started (https://social.technet.microsoft.com/Forums/scriptcenter/en-US/0e0e9c7f-5cdb-4647-a030-7fa7e18b2667/).

    On 64-bit Windows, 32-bit programs run in an emulation layer, and if you don’t like that, then don’t use the emulator

    This is about the 10th question you have posted about whatever it is you are trying to do.

    You need to explain the goal/purpose, not how you think it needs to be done. This is also known as the XY problem.


    -- Bill Stewart [Bill_Stewart]

    Monday, February 22, 2016 6:54 PM
    Moderator
  • Hello,
    Today, I build a other script to install a software.
    This script is running under a scheduled task launched at LOGON (standard user), through the SYSTEM account.

    Then, process explorer show me that everything is under 64 bits mode...very well !
    And one of these process is the HTA file with MSHTA.exe
    But the HTA file is not displayed inside the Windows Desktop of the user.
    Then, here, I provide a proof that the 64 bits mode is not the way to fix the issue.
    Is it because the script or the scheduled is running with the SYSTEM account ?
    Then, all the things done by SYSTEM can't be displayed to the end user ?
    The goal is now to export/import a scheduled task, not to create it through "schtasks /create ...".

    --
    I already try these commands :
    --
    call %SystemRoot%\system32\mshta.exe %Root_depot%\file.hta
    >> FAILED because the script is blocked.
    --

    start %SystemRoot%\system32\mshta.exe %Root_depot%\file.hta
    >> FAILED because the script is not displayed, but the script is not blocked.

    --

    Regards,




    • Edited by Cerkyr Tuesday, February 23, 2016 9:44 AM
    Tuesday, February 23, 2016 9:38 AM
  • Most of your issues seem to be because you do not have a very good technical understanding of Windows.  This leads you to try to do things that are not possible.

    If you run a logon script under the SYSTEM account it will only run when the system starts.  If there is a GUI it will cause the process to get stuck but the GUI will never be displayed.  This is just how Windows works.

    The bottom line is that you cannot  do what you are trying to do.  You cannot force software to install under a standard user account.  Try using Software Distribution with Group Policy or a computer Startup script.


    \_(ツ)_/

    Tuesday, February 23, 2016 9:48 AM
  • Hello,
    --
    "very good technical understanding of Windows."
    "This leads you to try to do things that are not possible."

    I'm sorry.
    Under Windows XP, this kind of script run and display our HTA files, each time, without any problem.
    Under Windows Seven 64 bits, it's not the case; then it's an issue to know how to fix or bypass this new problem that come from Windows Seven 64 bits.
    Why OK with XP, and not OK with Seven ?
    What are the différences ?
    UAC ?
    Other things ?

    --
    NOW, AN ADMIN CAN'T DISPLAY A HTA FILE FOR THE END USER ??!!
    --
    " You cannot force software to install under a standard user account."
    You don't understand. The script is running with SYSTEM account. Whe don't use AD. And the rest of the script install the software without any problem. Only HTA display is the problem. Your answer is NOT good.

    --
    Then, the way to build a scheduled task through XML file is done, but it doesn't fix the problem.

    On the XML file for the scheduled tasks, I check the box to enable the maximum rights.
    --


    • Edited by Cerkyr Tuesday, February 23, 2016 10:21 AM
    Tuesday, February 23, 2016 10:19 AM
  • You are either mistaken about Windows XP or you have altered the XP system in some way.  Remember that the scheduler in XP does not work like the scheduler in later versions.

    Also in Vista and later the UI is different.  It runs in a different mode and cannot be changed.


    \_(ツ)_/

    Tuesday, February 23, 2016 10:40 AM
  • It seems that there are 3 Windows Session per user :
    ID 0 = Logon
    ID 1 = Windows Desktop user (with icons ...)
    ID 2 = Screensaver
    Is it correct ?
    ---
    Then, only the ID1 can display something.
    Is it correct ?
    --
    Then, how to make a script run under ID1 ?

    Tuesday, February 23, 2016 11:06 AM
  • Don't know where you are getting that.  You can only display windows on a desktop.  The SYSTEM account does not have a desktop. SYSTEM is not a "logged in" account.  SYSTEM is the base process arena for all of Windows.  SYSTEM runs in and owns process 0.

    You cannot inject a script running in the "headless" SYSTEM process space into another process.  Processes are isolated from each other and the desktop is owned by a process that SYSTEM cannot write to as a UI.  SYSTEM can only manage the system and the resources of the system if the DACL allows it.  Processes in Windows cannot see each others memory.

    What you are trying todo cannot be done.  You can allow a user to use "RunAs" to launch an installer as an Admin or you can allow system to run the install with no output (silent).   You can run a task under the user account that can monitor a file and display messages from the SYSTEM task.


    \_(ツ)_/


    • Edited by jrv Tuesday, February 23, 2016 11:35 AM
    Tuesday, February 23, 2016 11:34 AM
  • Here is a suggestion that may help you sort out an answer.

    Post yo issues in the developers forum.  They can point you at code that can allow you to write from the system session to the desktop. It can be done with a driver and with a service.  I have done this n the past but do not have the code available.  It is fairly common and there are newer APIs that may make this even easier.  There just isn't anything in scripting that can do this.


    \_(ツ)_/

    Tuesday, February 23, 2016 12:11 PM
  • Then, the next goal is to build a script

    that build a Windows Service

    that run a process MSHTA with a HTA file

    and the the shedule task run the Windows Service

    that run the process MSHTA with the HTA file

    ...

    OK, let's try.

    Tuesday, February 23, 2016 12:24 PM
  • Then, the next goal is to build a script

    that build a Windows Service

    that run a process MSHTA with a HTA file

    and the the shedule task run the Windows Service

    that run the process MSHTA with the HTA file

    ...

    OK, let's try.

    That will still not show on the desktop.  MSHTA cannot output to a desktop in another session.  You can have it create an HTA that a task in the user session can run but the task will not have installer rights and you will not be able to output to the task.

    You can output to a file and have an HTA read the file repeatedly and show its contents.


    \_(ツ)_/

    Tuesday, February 23, 2016 12:36 PM
  • Here is the C++ developers forum. They can answer your questions. If you search you will find that this has been asked since the release of Vista.  You will see that there are many work-arounds.

    https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/home?category=windowsdesktopdev

    Here is a thread about, pretty much exactly, your issue.  It is from the Vista transition.  Note that Task Scheduler is a service and you are trying to get the service to "impersonate" SYSTEM.  TS can only output to a user session and only when the user I slogged in.  The following discussion explain why that is.

    https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/f8f91e8f-5954-43a7-8bc4-80ed2ff1e3b1/allow-service-to-interact-with-desktop-does-not-work-on-vista?forum=windowssdk


    \_(ツ)_/



    • Edited by jrv Tuesday, February 23, 2016 12:53 PM
    Tuesday, February 23, 2016 12:48 PM
  • I try the proposal to use the Windows Service.
    The MSHTA.exe process is running...
    Process Explorer show the command line , and inside a Desktop Windows , it works.
    But inside the process dedicated for the service, in 64 and 32 bits mode, the HTA doesn't appear.
    Then, again, FAIL.
    Tuesday, February 23, 2016 1:33 PM
  • There is no 32 bit mode for a service.  Service always run in the native architecture. MSHTA cannot run in a service and display on a desktop.

    \_(ツ)_/

    Tuesday, February 23, 2016 1:37 PM
  • Script must be stored in  GP shutdown folder to work.

    \_(ツ)_/

    Thursday, February 25, 2016 6:04 PM
  • Read this first:

    On 64-bit Windows, 32-bit programs run in an emulation layer, and if you don’t like that, then don’t use the emulator

    This is about the 10th question you have posted about whatever it is you are trying to do.

    You need to explain the goal/purpose, not how you think it needs to be done. This is also known as the XY problem.

    -- Bill Stewart [Bill_Stewart]

    Thursday, February 25, 2016 6:41 PM
    Moderator
  • Hello,
    I tried this without success.
    I'm going to test it again ...
    Regards,

    Monday, February 29, 2016 2:22 PM
  • Hello,
    I try with and without any file, inside the folder

    "C:\WINDOWS\system32\GroupPolicy\Machine\Scripts\Shutdown\"

    ...no change...the script is not executed.

    Then, something else is wrong. what ?

    Regards

    Monday, February 29, 2016 3:05 PM
  • Hello,

    "You need to explain the goal/purpose, not how you think it needs to be done." The goal is to execute a script at shutdown, but this mechanism must be applied with a other script, using the local assount System. it's mandatory. Regards,
    Monday, February 29, 2016 3:07 PM
  • "

    Read this first:

    On 64-bit Windows, 32-bit programs run in an emulation layer, and if you don’t like that, then don’t use the emulator

    "

    I can confirm that all the scripts are executed through 64 bits environment. I use the Sysinternals Process Explorer that show me that all the scripts are running in 64 bits environment.
    And yes, I can also confirm that the command "reg import <re_file>.reg" copy the keys and values , Inside the registry at 64 bits level and 32 bits level too; and this part is not clear, because I never ask to my script anthing at 32 bits level in the registry.

    Regards

    Monday, February 29, 2016 3:12 PM
  • Registry location 1:

    Windows Registry Editor Version 5.00
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\Scripts]
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Shutdown]
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Shutdown\0]
    "GPO-ID"="LocalGPO"
    "SOM-ID"="Local"
    "FileSysPath"="C:\\WINDOWS\\System32\\GroupPolicy\\Machine"
    "DisplayName"="Local Group Policy"
    "GPOName"="Local Group Policy"
    "PSScriptOrder"=dword:00000001
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Shutdown\0\0]
    "Script"="test_sd.ps1"
    "Parameters"="param1 param2"
    "IsPowershell"=dword:00000000
    "ExecTime"=hex(b):00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Startup]
    

    Registry location 2:

    Windows Registry Editor Version 5.00
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Scripts]
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Scripts\Shutdown]
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Scripts\Shutdown\0]
    "GPO-ID"="LocalGPO"
    "SOM-ID"="Local"
    "FileSysPath"="C:\\WINDOWS\\System32\\GroupPolicy\\Machine"
    "DisplayName"="Local Group Policy"
    "GPOName"="Local Group Policy"
    "PSScriptOrder"=dword:00000001
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Scripts\Shutdown\0\0]
    "Script"="test_sd.ps1"
    "Parameters"="param1 param2"
    "ExecTime"=hex(b):00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Scripts\Startup]
    

    You need both


    \_(ツ)_/


    • Edited by jrv Monday, February 29, 2016 3:37 PM
    Monday, February 29, 2016 3:36 PM
  • The Group Policy key is shared in both views.

    \_(ツ)_/

    Monday, February 29, 2016 4:02 PM
  • I try this afternoon without succes, but not with exactly your proposal...I will re-try it tomorrow morning.I'm thinking on scripts.ini file...is it necessary ?

    Wednesday, March 2, 2016 6:30 PM
  • The goal is to execute a script at shutdown

    But why do you need to execute a script at shutdown?


    -- Bill Stewart [Bill_Stewart]

    Wednesday, March 2, 2016 6:44 PM
    Moderator
  • Hello,
    It's because we need to install software and the final user doesn't have to be disturbed or interrupted during his job.
    Regards,
    Thursday, March 3, 2016 8:24 AM
  • Hello,

    This morning, I try your proposal, except that I don't user any Power Shell script.
    I use batch.
    Then, no change, the script is not executed at shutdown.

    Regards
    --

    Windows Registry Editor Version 5.00   

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\Scripts]

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Shutdown]

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Shutdown\0]
    "GPO-ID"="LocalGPO"
    "SOM-ID"="Local"
    "FileSysPath"="C:\\WINDOWS\\System32\\GroupPolicy\\Machine"
    "DisplayName"="Local Group Policy"
    "GPOName"="Local Group Policy"

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\Scripts\Shutdown\0\0]
    "Script"="%SystemRoot%\system32\cmd /C C:\\script_b.CMD"
    "Parameters"="param1 param2"
    "ExecTime"=hex(b):00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Scripts]   

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Scripts\Shutdown]   

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Scripts\Startup]   

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Scripts\Startup\0]   
    "GPO-ID"="LocalGPO"   
    "SOM-ID"="Local"   
    "FileSysPath"="C:\\Windows\\System32\\GroupPolicy\\Machine"   
    "DisplayName"="Stratégie de groupe locale"   
    "GPOName"="Stratégie de groupe locale"   

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Scripts\Shutdown\0]   
    "GPO-ID"="LocalGPO"   
    "SOM-ID"="Local"   
    "FileSysPath"="C:\\Windows\\System32\\GroupPolicy\\Machine"   
    "DisplayName"="Local Group Policy"
    "GPOName"="Local Group Policy"  

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Scripts\Startup\0\0]   
    "Script"="%SystemRoot%\system32\cmd /C C:\\script_b.CMD"
    "Parameters"=""   
    "ExecTime"=hex(b):00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00

    --

    Thursday, March 3, 2016 10:05 AM
  • Hello,
    It's because we need to install software and the final user doesn't have to be disturbed or interrupted during his job.

    What you are trying to do is going to be difficult, if not impractical, if you don't have software deployment tools that are designed for the task. I'm afraid you are asking for someone to help you complete a project that's doomed to fail. Sorry.


    -- Bill Stewart [Bill_Stewart]

    Thursday, March 3, 2016 3:35 PM
    Moderator
  • Hi,

    ----------------------------------------------------------------------------------------------------
    Yes, of course we have a software deployment tool.
    It's not the goal of the request...
    Did you understand why I make this issue ?
    Is it clear ?
    Do you need more explanation ?
    ----------------------------------------------------------------------------------------------------

    Let's come back to the issue :

    The goal is to make this,nder Microsoft Windows Seven Pro 64 bits : 
    + Write a script_A to build a local GPO to run a script_B at shutdown.

    Under Windows XP, it's working.
    Under Windows Seven 32 bits, it's working, too.
    But not on Windows Seven pro 64 bits.

    Why ?
    Where is the documentation for that ?

    Regards

    Friday, March 4, 2016 9:19 AM
  • The fact that it works in an older OS, and not now, is because Microsoft has improved security.

    Knowing why it worked in older versions and not now isn't going to help because it doesn't work now.

    We don't have the answer you want. Even if we did have the answer, it doesn't help you, because the answer isn't going to let you do something that doesn't work.

    You are going to need to approach your problem a different way.


    -- Bill Stewart [Bill_Stewart]


    Friday, March 4, 2016 3:36 PM
    Moderator
  • The solutions are done.
    Multiple things must be done to apply this kind of thing.
    I plan to build a documentation for that, in the future, less than 1 month.
    Regards,
    Friday, March 11, 2016 2:19 PM
  • The solutions are done.
    Multiple things must be done to apply this kind of thing.
    I plan to build a documentation for that, in the future, less than 1 month.
    Regards,
    Friday, March 11, 2016 2:22 PM
  • Microsoft Support recevie the need.

    Let's wait for the answer.

    Friday, March 11, 2016 2:22 PM
  • I close the issue.

    The solutions are done.
    Multiple things must be done to apply this kind of thing.
    I plan to build a documentation for that, in the future, less than 1 month.
    Regards,

    Friday, March 11, 2016 2:23 PM
  • The solutions are done.
    Multiple things must be done to apply this kind of thing.
    I plan to build a documentation for that, in the future, less than 1 month.
    Regards,
    Friday, March 11, 2016 2:24 PM
  • The solutions are done.
    Multiple things must be done to apply this kind of thing.
    I plan to build a documentation for that, in the future, less than 1 month.
    Regards,
    Friday, March 11, 2016 2:24 PM
  • The solutions are done.
    Multiple things must be done to apply this kind of thing.
    I plan to build a documentation for that, in the future, less than 1 month.
    Regards,
    Friday, March 11, 2016 2:25 PM
  • Hello,

    On a Windows 64 bits (seven), Inside the regisry, what is the VBS script that able to :

    write and  read on 64 bits

    write and read on 32 bits

    --

    On DOS Batch :

    It"s like that :

    reg add <key> /reg:64

    reg add <key> /reg:32

    Regards,

    Friday, August 26, 2016 9:44 AM