• Hm… ok, that was weird.

    1. The OSK on the client works on one server in the BIOS setup program. I.e. return and up/down keys work in the menu. (I don’t know why.)

    2. The OSK on the client does NOT work on the Windows Server Core login screen. (I don’t know why. Especially since it works in 1.)

    3. However, an American “” worked now. Perhaps this was fixed in one of the updates of the last few months.

    Perhaps MSFT found out (I told them and they seemed to ignore the issue) and fixed it.

    Or this was a fluke or someone reconfigured the keyboard layout of the server. Have to find out.

  • Ok, that was a confusing reply.

    1. Yes, there is a Swiss keyboard. I live in Switzerland. I know. I actually speak German and French. But I use a qwerty keyboard. I know there are servers that use a Swiss keyboar layout.

    2. You can doubt it, but I actually experienced it. ALT+ASCII doesn’t work on Server Core. I don’t think it matters that it is “not related to the GUI”.

    3. No, Num Lock was not a factor.

    4. There is no On-Screen Keyboard on a Server Core server. That actually IS related to the GUI.


  • Update: The described functionality is now part of ACLEdit.exe, same repo.

  • I think switching keyboards around based on the “nationality” of the server currently using is stupid.

    Besides, it’s not an option for our team in Singapore who have no access to Swiss keyboards but do (apparently) have a need to send a keyboard code produces by one to Swiss servers.

    I could solve the problem by having a US, a German, a French and a Swiss keyboard ready at my desk. Or perhaps there is a superkeyboard available somewhere that can send all sorts of international codes?


  • If I could connect via PowerShell remoting, I wouldn’t need to use the ILO.

    The company would also object to me changing the system’s general keyboard layout for the login screen (which is the default keyboard layout for all users).

    “So if you have physical access, you can logon and then change the keyboard layout.”

    If I had physical access, I also wouldn’t need to to use the ILO. However, I now assume I would have the same issue logging on. If logging in requires me to type a Swiss
    “” and my keyboard doesn’t have that key, I won’t be able to logon. So I think the issue is really with Windows Server and not with ILO.

    Windows Server Desktop allows changing the keyboard layout on the login screen, Windows Server Core does not. I really don’t know how MSFT imagined this should work.

    (I think perhaps they imagine a world where different keyboard layouts don’t exist, just like they imagine a world in which every server everywhere is always connected to the Internet and hence PowerShell modules don’t have to come with help files because they can be downloaded at will, in MSFT-land.)


  • I just encountered an annoying issue.

    When trying to log onto Windows Server Core via ILO using a local account, it is impossible to type a backslash if the server’s keyboard layout is too foreign.

    In my case it’s a Swiss keyboard layout. Swiss keyboards apparently have a key between z and left-shift that (in combination with alt-gr, another special key on the Swiss keyboard) types . My American keyboard doesn’t have that key.

    I tried:

    1. Changing the keyboard layout in the console. This fails because ILO does not, apparently, send shift-alt through to the server.

    2. Typing left-alt and 9 and 2 on the numberpad to get ASCII . This fails because Server Core apprently doesn’t support this handy input method. (It acts as if I pressed return.)

    3. Using / instead of .

    4. Using @servername instead of servername. (Obviously this didn’t work.)

    5. Using ILO hotkeys, which apparently cannot send foreign keycodes either. becomes $ (because a Swiss keyboard has $ where an American has ).

    6. Calling a colleague with a Swiss keyboard. That worked, but is not practical at all hours.

    How did HPE think this should work? What am I overlooking?

  • For what it’s worth, I tried it without C# or PowerShell.

    Using SetNamedSecurityInfo() it appears to be possible to set a new DAC on an object owned by me without either Set Value or Write DACL set (and obviously without being an administrator).

    Originally Benoit has full control on his key:

    I then got SDDLs for Full Control and two versions for without Set Value and without Write DAC

    And finally I wrote that SDDL over the existing DACL

    It appears that .NET ignores the fact that the owner can modify the DACL without any specific permissions set.

    Now, I tried the same thing with opening registry keys and writing security descriptors to them (without using SetNamedSecurityInfo()) and then I found the same behaviour as with .NET: I could only change a DACL if I had Set Value. Perhaps .NET (and thus both C# and PowerShell) set registry permissions using RegSetKeySecurity() rather than SetNamedSecurityInfo().

    I didn’t try if Write DAC becomes relevant if I am not the owner of the key, I assume it does.

    Hope this helps someone else who has this problem in a script.

    The (not very good and entirely non-error-checking) code can be found here: https://github.com/ajbrehm/ABTokenTools

  • I am not talking about admins, but about an ACL. There is no “Set Value” privilege, it’s a permission in the ACL. In order for my user to have that permission, it has to be set by someone who has that permission. The owner of the key should be able to set that permission and, with regedit, can.

    But that doesn’t help with a script, for example.

    My question is not about UAC or about admins, it’s only about a problem with .NET where an ACL is obviously interpreted differently as by Win32 (which is why regedit works).

    A user who owns a key should be able to modify the key’s ACL. With C# and PowerShell he cannot, and I was wondering about that.

    I will try another way now and see if it’s purely a .NET issue.

  • What are you talking about? It’s not admins but owners who can set permissions on objects*. Plus as I said this affects Administrators just as much as other users.

    (*Administrators have SeTakeOwnershipPrivilege and with this can take ownership of an object and then set permissions. But this won’t work here because even if Administrators is owner of the registry key, setting permissions with PowerShell or C# still won’t work, as stated in the question.)


  • Yes, both the PowerShell window and the C# test program ran elevated. In fact, it wouldn’t matter, because as mentioned, this happens with both permissions for the user himself and permissions for the Administrators group.

    Also as mentioned, when the user has “Set Value”, he can change permissions, so the user is affected by the key’s permissions. But “Write DACL” appears not to have an effect and “Set Value” can only be set by a user who has “Set Value” which is somehow pointless.


  • I am trying to change permissions on a registry key owned by my user.

    Using RegEdit it works, regardless of whether my user has “Set Value” and/or “Write DAC”.

    But using PowerShell (or C#), changing permissions only works if my user has “Set Value”, regardless of the value of “Write DAC”.

    The same applies to a member of the Administrators group when the key is owned by Administrators. “Set Value” appears to allow changing permissions, “Write DAC” is ignored, with RegEdit it works.

    How is it possible to set “Set Value” without using RegEdit when it isn’t already set?

    This is on Windows 10.0.19042.1466.

  • Yes, that is not possible. The Exchange team say that Exchange’s log file folder MUST remain as created, i.e. with permissions for only Administrators, because otherwise, MSFT told them, MSFT would not support it.

    I know I can test this theoretically. But corporate reality is that service owners do not want to lose permissions and are less than helpful when you ask them to check if they can work with fewer permissions. It’s always the same: principle of least privilege is a great but obviously not in our situation/for our application.

    Our company is too large to have one team for Windows Server and Exchange. There are lots of other applications with the same issue as well. We cannot just make all those hundreds of people into one team with essentially the same job description.

    We have similar issues with IIS (iismgr.exe refuses to work withoout admin rights, fixed via self-created “sudo” for Windows), Sharepoint (team say it falls apart completely if a certain icon is clicked without the clicker having admin rights), Tableau (has a cmd file that looks for a java.exe and then runs a Java program base64-encoded into the same batch file, won’t run without admin rights),  and basically every piece of “enterprise software” imaginable. All “require” admin rights and the vendors never care to provide what permissions their software really needs or why and they just check whether they are run as admin and that’s what they support.

    Of course, Microsoft themselves are among the worst perpetrators of this custom.

    VMS had a feature that would give a certain image certain privileges, but Windows doesn’t have that (or at least I haven’t found it yet). A Unix-like sudo is also not a good answer because the vast majority of Windows applications allow users to start programs from the open-file/save-file dialogue, rendering a sudo-based approach useless. (Tableau is a special case because it actually looks for a java.exe and hence anyone can provide it an exe file of their choice.)

    I am now looking into an approach where a job object limits the number of processes running within it with admin rights to one (the first started) but even that will not necessarily help with Exchange.

  • Andrew Brehm's profile was updated 2 years, 10 months ago

  • For a while now I have been trying to find out whether an Exchange admin has to be a local admin on the Exchange server.

    Answers in MSFT forums are contradictory.

    Most do not understand the question and keep saying that they do not have to be domain admins. (That was never an issue.)

    The others say that they don’t have to be sysadmins but when asked about Exchange log files being readable only by the Administrators group, they also refer to the domain admin thing.

    Does anyone here know what the correct RBAC configuration is for Exchange? We don’t want application admins to be sysadmins and MSFT appear not to want to tell anyone what permissions an Exchange admin really needs on an Exchange server.

    Any ideas?

  • MSFT appear not to have updated their documentation on Nano Server since 2017 and all information appears to be wrong or out-of-date.

    The NanoServerPackage module cmdlets don’t work for me:

    PS C:UsersuserDocuments> Find-NanoServerPackage
    WARNING: Cannot find path ‘C:UsersuserAppDataLocalNanoServerPackageProvidersearchNanoPackageIndex.txt’
    because it does not exist.
    WARNING: Save-HTTPItem: Bits Transfer failed. Job State:  ExitCode = -2147023651

    And there are no Nano Server packages on the Server 2019 ISO that I can find. (Apparently they were on the 2016 ISO.)

    All documentation I can find refers either to the NanoServerPackage module last updated in 2016 (which doesn’t work) or to the NanoServer packages being on the ISO (which is not true for Server 2019).

    Does anyone know how I am supposed to install, for example, IIS on a NanoServer Docker image?

    (Note that I am not looking for a way to download a read-made image with NanoServer and IIS. I want a generic answer.)

    Any ideas?

  • Andrew Brehm changed their profile picture 2 years, 10 months ago

  • Andrew Brehm became a registered member 2 years, 10 months ago

© 4sysops 2006 - 2023


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account