Для начала было бы логично заглянуть в журнал событий, но подозреваю, что они в системах в угоду производительности отключены. Так что если переходить исключительно к фактам, то, во-первых, проблема может таиться в брокере безопасности (в политиках указано одно, а брокер их попросту игнорирует), во-вторых, на реестр полагаться не следует, так как для самой MS реестр сродни некой складчине наследия, которое они от релиза к релизу грозятся упорядочить, но воз и ныне там. Возможно последнее является предпосылкой для различного рода недокументированных API, например, CheckElevationEnabled в kernel32.dll (сигнатура:
Код:
DWORD CheckElevationEnabled(
PBOOL pEnabled
);
), являющейся оберткой над RtlQueryElevationFlags из ntdll.dll (сигнатура:
Код:
NTSYSAPI
NTSTATUS
NTAPI
RtlQueryElevationFlags(
PRTL_ELEVATION_FLAGS Flags
);
), где RTL_ELEVATION_FLAGS - это объединение (union) для поля SharedDataFlags (смещение 0x2F0) и ряда битовых полей структуры KUSER_SHARED_DATA. В общем, если не заморачиваться с низкоуровневой реализацией вышеупомянутых функций, проверить включен ли UAC в pwsh можно теоретически так:
Код:
!!([Runtime.InteropServices.Marshal]::ReadInt32([IntPtr]0x7ffe02f0) -band 2)
