Hello Klaus,
I'm also facing a similar issue.
Setting registry keys for HK_LOCAL_MACHINE works usually fine because those are available for any user.
I have a package that does the following at the "On Installation End" step:
NwEngine.Shell.SetRegValue "HKEY_LOCAL_MACHINE\Software\SAP\SAPGUI Front\SAP Frontend Server\Security\SecurityLevel", "REG_DWORD", "0"
NwEngine.Shell.SetRegValue "HKEY_LOCAL_MACHINE\Software\Wow6432Node\SAP\SAPGUI Front\SAP Frontend Server\Security\SecurityLevel", "REG_DWORD", "0"
NwEngine.Shell.SetRegValue "HKEY_LOCAL_MACHINE\Software\SAP\SAP Shared\SaphistoryDir", "REG_EXPAND_SZ", "%APPDATA%\SAP\SAP GUI\History"
NwEngine.Shell.SetRegValue "HKEY_LOCAL_MACHINE\Software\Wow6432Node\SAP\SAP Shared\SaphistoryDir", "REG_EXPAND_SZ", "%APPDATA%\SAP\SAP GUI\History"
NwEngine.Shell.SetRegValue "HKEY_LOCAL_MACHINE\Software\SAP\SAP Shared\SapWorkDir", "REG_EXPAND_SZ", "%USERPROFILE%\SapWorkDir"
NwEngine.Shell.SetRegValue "HKEY_LOCAL_MACHINE\Software\Wow6432Node\SAP\SAP Shared\SapWorkDir", "REG_EXPAND_SZ", "%USERPROFILE%\SapWorkDir"
Problem with CURRENT_USER registry keys and such a silent installation is that usually the installation is performed under a service user (for instance using Microsoft SCCM) that has admin rights on the machine to perform any software installation.
Then you try to launch SAPGUI but usually with a different user than the one used to perform the installation.
Of course this user won't see the registry settings that are supposed to be set because those ones are only available for the user who performed the installation.
I also noticed that most of these related CURRENT_USER registry keys don't have an equivalence as LOCAL_MACHINE registry keys unfortunately.
Examples of keys (to disable transaction/ok-code field) that are user specific:
[HKEY_CURRENT_USER\SOFTWARE\SAP\SAPGUI Front\SAP Frontend Server\Customize]
"CmdLine.DisableWhenInvisible"=dword:00000001
"HideCmdLineInplace"="1"
"HideCmdLineInplaceAllSession"="1"
To bypass such a problem in my company we are using tools (regcloner.exe) that are copying registry keys from the LOCAL_MACHINE area to CURRENT_USER area at logon time of the user. It is the concept of Shadow Keys. Note that you can manage it without any particular tool. Usually a bit of Windows scripting might be sufficient (refer to REG command as well).
A potential solution would be that your package generated on your SAPGUI installation server could set within LOCAL_MACHINE (you can define your own keys storage) all the keys you need for CURRENT USER.
Example for "On Installation End" step:
NwEngine.Shell.SetRegValue "HKEY_LOCAL_MACHINE\Software\MYCOMPANY\SAPGUI_HK_CU\SOFTWARE\SAP\SAPGUI Front\SAP Frontend Server\Customize\CmdLine.DisableWhenInvisible", "REG_DWORD", "1"
Then you you need to set up a script that can be called by your logon script (refer to MS litterarure on how logon scripts are set) with the help of the REG QUERY command you might be able to read the registry key set above from LOCAL_MACHINE, retrieve the information you need from the returned string, probably set a couple of variables and run REG ADD command to set the registry keys for CURRENT_USER.
This will require a bit of Windows scripting but it is achievable.
There are pros and cons for this approach:
Pros:
Registry Keys are set according to your expectation.
Cons:
If the user wants to set its own SAPGUI settings that are already covered by yours, he/she will lose his/her own settings at next logon.
So you really have to identify what the user is allowed to configure in SAPGUI configuration and what you want to force.
Hope you will get the idea. However it will be good to get advices from SAP colleagues to see if they have better ideas.
Regards, Christophe