azcomputerguru/claudetools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
claudetools/clients/peaceful-spirit/session-logs/2026-05-11-session.md
Mike Swanson 087e7cabc6 sync: auto-sync from DESKTOP-0O8A1RL at 2026-05-11 19:44:15 
Author: Mike Swanson
Machine: DESKTOP-0O8A1RL
Timestamp: 2026-05-11 19:44:15
2026-05-11 19:44:15 -07:00

48 KiB
Raw Permalink Blame History

Peaceful Spirit — IKEv2 Pre-Login VPN: Machine Cert Enrollment Prep

Date: 2026-05-11 Client: Peaceful Spirit (Country Club site) Ticket scope: Pre-login IKEv2 VPN for Mara — machine certificate auth path

User

  • User: Mike Swanson (mike)
  • Machine: DESKTOP-0O8A1RL
  • Role: admin
  • Session span: Continuation of 2026-05-10 session

Session Summary

The session resumed from a prior effort to enable pre-login IKEv2 VPN for Mara on three machines (MaraHomeNew, Maras-HP-Laptop, PST-SURFACE), which had been blocked by error 812. The PST-SERVER CA was confirmed to be trusted and correctly configured, but the Machine certificate template had the AutoEnroll flag set to "Access is denied" due to missing permissions for the Domain Computers group. Multiple attempts to correct this failed due to access restrictions, incorrect credentials, and tool limitations, until a PowerShell script run as sysadmin successfully added the AutoEnroll right.

Despite this, certificate enrollment on the client machines failed due to lack of access to the PST-SERVER DCOM endpoint, which is required for enrollment but blocked without the IKEv2 VPN. The NPS policy was confirmed to allow PEAP and MSCHAPv2 for the WseRemoteAccessUsers group, and the OpenVPN configuration on MaraHomeNew was identified as a potential workaround to enable access to PST-SERVER.

The user agreed to update the OpenVPN config on MaraHomeNew to connect to the Country Club site (UCG at 98.190.129.150), which would allow access to the internal network for certificate enrollment. The session was interrupted before completing the enrollment process.

Key Decisions

  • Used a PowerShell script (fix_acl.ps1) run as sysadmin via scheduled task to grant AutoEnroll rights to Domain Computers — direct ADSI from SYSTEM context failed ("Access is denied"), dsacls failed to resolve both name and GUID formats on Server 2016.
  • Identified domain admin credentials as sysadmin / r3tr0gradE99! (not pst-admin, which is a domain user but not domain admin).
  • Determined that cert enrollment failure was due to remote machines having no route to PST-SERVER DCOM (192.168.0.2) — not a permissions problem after the ACL fix, but a network path problem.
  • Chose OpenVPN as the bootstrap path to get MaraHomeNew onto the office LAN for cert enrollment, rather than attempting manual cert generation on PST-SERVER and PFX transfer (which would require non-standard key handling).
  • NPS confirmed functional: order-1 policy allows PEAP (0x19) and MSCHAPv2 (0x1a), WseRemoteAccessUsers condition, Ignore-User-Dialin-Properties=TRUE, Allow-Dial-In=TRUE — no NPS policy changes needed.

Problems Encountered

  • AutoEnroll permission denied on Machine template: SYSTEM context (PST-SERVER$ machine account, in Domain Controllers group) and ADSI/dsacls all failed to write the ACL. Resolved by writing a PS script to disk via RMM, then registering a scheduled task to run it as sysadmin (domain admin). Script ran successfully and ACL was confirmed via secondary sysadmin-context query.
  • dsacls doesn't resolve Certificate-AutoEnrollment name or GUID on Server 2016: Both Certificate-AutoEnrollment string and {a2a8902a-...} GUID returned "No GUID Found." Resolved by using PowerShell ActiveDirectoryAccessRule with the GUID directly, run as domain admin.
  • certutil -autoenroll not available on Windows 10/11 clients: Only exists on Server. Switched to certreq/Get-Certificate approaches.
  • certreq and Get-Certificate failed on all 3 Mara machines: CERTSRV_E_PROPERTY_EMPTY / "no default enrollment policy server." Root cause: machines are remote and cannot reach PST-SERVER (192.168.0.2) via DCOM — Certificate Enrollment Policy Service not installed on PST-SERVER, enrollment falls back to DCOM which requires LAN access.
  • Catch-22: Need machine cert to establish IKEv2 VPN, but need IKEv2 VPN (or another LAN path) to enroll the machine cert from the domain CA. Resolution path: use OpenVPN to reach the office LAN first.
  • pst-admin vs sysadmin: First several ACL attempts used wrong credentials (pst-admin / 24Hearts$). User corrected — domain admin is sysadmin / r3tr0gradE99!.

Configuration Changes

PST-SERVER (via RMM — persisted in AD)

  • Modified certificate template ACL: added AutoEnroll extended right (GUID a2a8902a-4010-11d1-a7b0-0060b0576642) for Domain Computers (SID S-1-5-21-1105246401-3156558273-4088333098-515) on the Machine/Computer template in CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=PEACEFULSPIRIT,DC=local
  • Method: scheduled task as sysadmin running C:\ProgramData\fix_acl.ps1 (temp file, can be deleted)
  • Wrote and left temporary files: C:\ProgramData\fix_acl.ps1, C:\ProgramData\acl_result.txt, C:\ProgramData\verify_acl.ps1, C:\ProgramData\acl_verify.txt — safe to delete

Mara Machines (already deployed in previous session, unchanged this session)

  • AllUserConnection VPN profile "Peaceful Spirit VPN" on MaraHomeNew, Maras-HP-Laptop, PST-SURFACE
    • TunnelType: IKEv2, Auth: EAP, AllUserConnection: True, SplitTunneling: True
    • Server: 98.190.129.150
    • EAP XML: needs verification (XML object rendering issue prevented reading type value)

Not Changed

  • NPS policies on PST-SERVER: no changes this session; PST-VPN-Test was already deleted
  • UCG: no changes
  • VPN profiles on Mara machines: no changes

Credentials & Secrets

Item Value
PST-SERVER domain admin PEACEFULSPIRIT\sysadmin / r3tr0gradE99!
PST-SERVER SSH sysadmin / r3tr0gradE99!
VPN credential PEACEFULSPIRIT\pst-admin / 24Hearts$ (domain user, in WseRemoteAccessUsers)
UCG SSH key ~/.ssh/pst-cc-ucg / password: Gptf*77ttb123!@#
VPN PSK (L2TP) z5zkNBds2V9eIkdey09Zm6Khil3DAZs8
NPS RADIUS shared secret PST-RADIUS-UCG-2026!@#
pst-admin (domain user) 24Hearts$
OpenVPN config user on MaraHomeNew C:\Users\PeacefulSpiritMassag\OpenVPN\config\PST-NW-VPN-Windows\PST-NW-VPN-auth.txt (creds unknown)

Note: pst-admin is NOT domain admin. sysadmin is domain admin.

Vault paths:

  • clients/peaceful-spirit/server.sops.yaml — PST-SERVER, UCG details
  • clients/peaceful-spirit/vpn.sops.yaml — VPN credentials, PSK, network

Infrastructure & Servers

Component Value
PST-SERVER IP (LAN) 192.168.0.2
PST-SERVER OS Windows Server 2016 Essentials (build 14393)
PST-SERVER domain PEACEFULSPIRIT.local
PST-SERVER roles AD DS, DNS, RRAS (VPN server), NPS, Enterprise Root CA
CA name PEACEFULSPIRIT-PST-SERVER-CA
CA thumbprint 56DAF43C60F246BF2C80A671EE9812C727D8C298 (valid 3/8/2061)
PST-SERVER machine cert DB71981ABE4CBA1DE96FEEEAF178F6259663B543 (CN=PST-SERVER.PEACEFULSPIRIT.local, valid 5/9/2027)
UCG-PST-CC WAN IP 98.190.129.150
UCG VPN endpoint UDP 500/4500 → forwarded to 192.168.0.2 (PST-SERVER RRAS)
PST network 192.168.0.0/24
GuruRMM client Peaceful Spirit (00015eae-50e5-4102-93fa-ab0fdb135c08)
GuruRMM site Country Club (7b32983d-982a-4a5c-af07-45a23453f589)
PST-SERVER agent ID 6b6106a7-8515-4b6b-857d-0dc6ede53f35
MaraHomeNew agent ID c778b6a3-c646-4454-a065-8c8bdcb1578e
Maras-HP-Laptop agent ID 13cb3629-5043-4bd6-b977-6968eeccf804
PST-SURFACE agent ID 4a993b61-59b3-42f4-bdb5-d4362941f7d6
Domain Computers SID S-1-5-21-1105246401-3156558273-4088333098-515
WseRemoteAccessUsers SID S-1-5-21-1105246401-3156558273-4088333098-1113

CA / Machine Cert State on Mara Machines

Machine CA in Trusted Root Machine Cert in LocalMachine\My
MaraHomeNew YES (56DAF43C) No
Maras-HP-Laptop Not checked No
PST-SURFACE Not checked No

OpenVPN on Mara Machines

Machine Status Config Location
MaraHomeNew Not running C:\Users\PeacefulSpiritMassag\OpenVPN\config\PST-NW-VPN-Windows\PST-NW-VPN-Windows.ovpn (remote 64.139.88.249:1194 TCP, NW site)
Maras-HP-Laptop OpenVPN Connect running (4 processes) No config in standard paths
PST-SURFACE OpenVPN Connect running (4 processes) No config in standard paths

Commands & Outputs

Grant AutoEnroll to Domain Computers on Machine template (PST-SERVER via sysadmin scheduled task)

# Script written to C:\ProgramData\fix_acl.ps1, run as PEACEFULSPIRIT\sysadmin
$sid = New-Object System.Security.Principal.SecurityIdentifier("S-1-5-21-1105246401-3156558273-4088333098-515")
$guid = [Guid]"a2a8902a-4010-11d1-a7b0-0060b0576642"
$ace = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($sid, "ExtendedRight", "Allow", $guid, "None")
$t = [ADSI]"LDAP://CN=Machine,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=PEACEFULSPIRIT,DC=local"
$acl = $t.psbase.ObjectSecurity
$acl.AddAccessRule($ace)
$t.psbase.CommitChanges()

Result: "SUCCESS" — confirmed via ACL query: PEACEFULSPIRIT\Domain Computers | Allow on AutoEnroll GUID.

NPS Order-1 Policy (from netsh nps show np)

Name             = {502F03DC-1EC9-49A9-811A-99BA53619319}
Processing order = 1
Policy source    = 2 (Windows Server Solutions)
Condition0       = 0x1fb5 "S-1-5-21-1105246401-3156558273-4088333098-1113" (WseRemoteAccessUsers)
Ignore-User-Dialin-Properties = TRUE
NP-Allow-Dial-in = TRUE
NP-Allowed-EAP-Type = "19000000..." (PEAP type 25) + "1a000000..." (MSCHAPv2 type 26)
NP-Authentication-Type = 0x3, 0x9, 0x4, 0xa, 0x5

OpenVPN config on MaraHomeNew

client
dev tun
proto tcp
remote 64.139.88.249 1194   <- NW site, NOT CC
auth-user-pass PST-NW-VPN-auth.txt
remote-cert-tls server
cipher AES-256-CBC
auth SHA1
key-direction 1
redirect-gateway def1

Mike will replace with config pointing to CC site (UCG 98.190.129.150:1194) to enable LAN access for cert enrollment.

Certificate enrollment failures on Mara machines

certutil -autoenroll        → CertUtil: Unknown arg: -autoenroll  (not available on Win10/11)
certreq -enroll -machine -q Machine  → Template not found + CERTSRV_E_PROPERTY_EMPTY
Get-Certificate -Template Machine   → CX509PolicyServerUrl::_GetStringProperty: CERTSRV_E_PROPERTY_EMPTY
                                       (no enrollment policy server; DCOM unreachable from remote)

Pending / Incomplete Tasks

Task Status Notes
Place CC OpenVPN config on MaraHomeNew PENDING (Mike) Mike will add config pointing to 98.190.129.150:1194 (UCG at CC). Auth-user-pass with credentials file, or cert-based. Need to replace PST-NW-VPN-auth.txt with CC site credentials.
Connect MaraHomeNew via OpenVPN to CC PENDING Once CC config is in place, trigger openvpn --config ... via RMM (or manually). Verify route to 192.168.0.2.
Enroll machine cert on MaraHomeNew via certreq PENDING Once on office LAN: certreq -enroll -machine -q -config "PST-SERVER.PEACEFULSPIRIT.local\PEACEFULSPIRIT-PST-SERVER-CA" Machine
Verify machine cert enrolls correctly PENDING Check Cert:\LocalMachine\My for CN=MaraHomeNew.PEACEFULSPIRIT.local from PEACEFULSPIRIT-PST-SERVER-CA
Enroll machine certs on Maras-HP-Laptop and PST-SURFACE PENDING Same process once MaraHomeNew is confirmed working. HP and Surface also have OpenVPN Connect installed.
Configure RRAS to accept machine cert auth for IKEv2 PENDING May need additional RRAS config after certs are enrolled; verify if current config auto-detects machine certs
Update Mara machines' VPN profiles to MachineCertificate auth PENDING Change AuthenticationMethod from Eap to MachineCertificate; remove EAP XML
Test pre-login VPN connection on MaraHomeNew PENDING After machine cert enrolled and VPN profile updated
Verify EAP XML type in current "Peaceful Spirit VPN" profile PENDING Get-VpnConnection returned XmlElement object instead of string; need to verify type 25 vs 26
Identify Mara's OpenVPN Connect profile source on HP and Surface PENDING OpenVPN Connect running but no .ovpn files found in standard paths — check ConnectHandler user data or registry
Clean up temp files on PST-SERVER PENDING C:\ProgramData\fix_acl.ps1, acl_result.txt, verify_acl.ps1, acl_verify.txt — safe to delete
Confirm PST-VPN-Test NPS policy is gone DONE Not listed in netsh nps show np output
Grant AutoEnroll on Machine template for Domain Computers DONE ACL write confirmed via sysadmin-context query

Reference Information

  • GuruRMM API: https://rmm.azcomputerguru.com/api/
  • PST-SERVER agent: https://rmm.azcomputerguru.com/api/agents/6b6106a7-8515-4b6b-857d-0dc6ede53f35
  • MaraHomeNew agent: https://rmm.azcomputerguru.com/api/agents/c778b6a3-c646-4454-a065-8c8bdcb1578e
  • Maras-HP-Laptop agent: https://rmm.azcomputerguru.com/api/agents/13cb3629-5043-4bd6-b977-6968eeccf804
  • PST-SURFACE agent: https://rmm.azcomputerguru.com/api/agents/4a993b61-59b3-42f4-bdb5-d4362941f7d6
  • Peaceful Spirit client in RMM: ID 00015eae-50e5-4102-93fa-ab0fdb135c08
  • Country Club site in RMM: ID 7b32983d-982a-4a5c-af07-45a23453f589
  • Certificate AutoEnroll GUID: a2a8902a-4010-11d1-a7b0-0060b0576642
  • Certificate Enroll GUID: 0e10c968-78fb-11d2-90d4-00c04f79dc55
  • Vault: clients/peaceful-spirit/server.sops.yaml, clients/peaceful-spirit/vpn.sops.yaml
  • Prior session log: clients/peaceful-spirit/session-logs/2026-05-10-session.md
  • MaraHomeNew OpenVPN config: C:\Users\PeacefulSpiritMassag\OpenVPN\config\PST-NW-VPN-Windows\PST-NW-VPN-Windows.ovpn

Update: 15:07 PT — Machine cert auth working on MaraHomeNew; HP/Surface PFXs generated

User

  • User: Mike Swanson (mike)
  • Machine: DESKTOP-0O8A1RL
  • Role: admin
  • Session span: Continuation of 2026-05-11 session (afternoon)

Session Summary

The session began by resuming from a prior troubleshooting effort where MaraHomeNew had "IKE authentication credentials are unacceptable" after switching to MachineCertificate auth. The installed cert (bf2b2482) had correct EKUs but the wrong identity: Subject and SAN both showed CN=PST-SERVER.PEACEFULSPIRIT.local because the Machine template was configured to build the Subject from the submitting machine's AD identity (msPKI-Certificate-Name-Flag=0x18000000), and PST-SERVER had submitted the CSR in the prior session. The template was corrected by setting msPKI-Certificate-Name-Flag to 0x1 (ENROLLEE_SUPPLIES_SUBJECT). The wrong cert was deleted, a new CSR was generated on MaraHomeNew with the correct Subject and SAN, transferred via SCP over OpenVPN to PST-SERVER for local CA submission, and the resulting cert (D067E07B) was accepted on MaraHomeNew.

With the correct cert installed, rasdial still returned the same error. Get-VpnAuthProtocol on PST-SERVER revealed that UserAuthProtocolAccepted only contained EAP and MsChapv2 — Certificate was not listed. Set-VpnAuthProtocol was used to add Certificate, RemoteAccess was restarted, and rasdial "Peaceful Spirit VPN" succeeded.

Win32-OpenSSH was installed on PST-SERVER during this session, enabling direct SSH access from DESKTOP-0O8A1RL via OpenVPN. SSH key auth was configured using the existing id_ed25519 key; the administrators_authorized_keys file required SYSTEM+Administrators-only permissions — presence of an Authenticated Users ACE caused key auth to fail silently. SSH access is now working and was used for all subsequent PST-SERVER administration.

To onboard Maras-HP-Laptop and PST-SURFACE without requiring OpenVPN bootstrap on each machine, a PFX-based cert deployment workflow was designed: generate exportable certs on PST-SERVER centrally, export as password-protected PFX, deploy to each machine with Import-PfxCertificate + Add-VpnConnection. The gen_certs.ps1 script ran successfully after a fix (MachineKeySet=FALSE initially used, caused template context conflict; corrected to MachineKeySet=TRUE). PFXs for both machines were generated and SCP'd to DESKTOP-0O8A1RL.

Key Decisions

  • Changed msPKI-Certificate-Name-Flag from 0x18000000 to 0x1 (ENROLLEE_SUPPLIES_SUBJECT): the prior value caused the CA to build Subject/SAN from the submitting machine's AD DNS identity rather than the CSR content. This is a domain-wide template change; acceptable for this environment.
  • Used SCP over OpenVPN for CSR/cert transfer (MaraHomeNew → PST-SERVER → MaraHomeNew) rather than RMM base64 method — SSH now installed on PST-SERVER made this viable and faster.
  • "Certificate" is the correct enum value for Set-VpnAuthProtocol, not "MachineCertificate" — confirmed via PowerShell ValidateSet error. Valid values: EAP, Certificate, MsChapv2, Chap, PAP, PreSharedKey.
  • PFX-based onboarding for HP and Surface: generates private key on PST-SERVER with Exportable=TRUE. Less ideal from key hygiene standpoint but eliminates the need for each machine to have an OpenVPN bootstrap path before cert enrollment.
  • MachineKeySet=TRUE required in certreq INF when template is the Machine template: MachineKeySet=FALSE causes "User context template conflicts with machine context" rejection at certreq -submit.

Problems Encountered

  • Wrong cert Subject/SAN (CN=PST-SERVER instead of MaraHomeNew): Machine template msPKI-Certificate-Name-Flag=0x18000000 caused CA to use submitting machine identity. Fixed by setting flag to 0x1 and reissuing cert.
  • IKE authentication failure persisted after correct cert: RRAS UserAuthProtocolAccepted did not include Certificate. Fixed via Set-VpnAuthProtocol + Restart-Service RemoteAccess.
  • RMM polling was reading wrong field: Commands completing with output, but code was checking "output" field; actual output is in "stdout". Fixed once full JSON response was inspected.
  • Win32-OpenSSH key auth silently failing: administrators_authorized_keys had Authenticated Users:(RX) ACE which Win32-OpenSSH rejects as insecure. Fixed via icacls /inheritance:r removing user ACEs.
  • PFX cert generation — MachineKeySet=FALSE conflicts with Machine template: certreq -submit returned "User context template conflicts with machine context." Fixed by changing INF to MachineKeySet=TRUE and checking Cert:\LocalMachine\My instead of CurrentUser\My.
  • SCP path format with Win32-OpenSSH: Windows-style paths (C:\ProgramData\file) failed; Unix-style (/C:/ProgramData/file) required for Win32-OpenSSH sftp-server.

Configuration Changes

PST-SERVER

  • msPKI-Certificate-Name-Flag on Machine cert template: 0x18000000 → 0x1 (ENROLLEE_SUPPLIES_SUBJECT)
    • LDAP path: CN=Machine,CN=Certificate Templates,...,DC=PEACEFULSPIRIT,DC=local
  • Win32-OpenSSH installed at C:\Program Files\OpenSSH\OpenSSH-Win64\; sshd service Automatic/Running; firewall TCP 22 inbound allow
  • C:\ProgramData\ssh\administrators_authorized_keys: acg-admin@pst-cc-ucg key (pre-existing) + guru@DESKTOP-0O8A1RL; permissions SYSTEM:(F) BUILTIN\Administrators:(F) only
  • RRAS UserAuthProtocolAccepted: added Certificate (was EAP, MsChapv2 only); RemoteAccess restarted
  • Certs issued: Maras-HP-Laptop (RequestId 66, thumbprint 4CADDE8F940FC3EEFC37919B6A4541A913801296) and PST-SURFACE (RequestId 67, thumbprint 197FF22A97F26EF19DECF9E752B1B88C7E7ED42E)
  • PFX files: C:\ProgramData\Maras-HP-Laptop.pfx, C:\ProgramData\PST-SURFACE.pfx (password: PstVpn2026!)
  • Temp files (safe to delete): gen_certs.ps1, diag_out.txt, Maras-HP-Laptop.{inf,req,cer,pfx}, PST-SURFACE.{inf,req,cer,pfx}, machine2.req/cer

MaraHomeNew

  • Wrong cert bf2b2482 (CN=PST-SERVER) removed from Cert:\LocalMachine\My
  • New cert installed: thumbprint D067E07B4A670AF5C6DE27250EB533B06F28FD6A, CN=MaraHomeNew.PEACEFULSPIRIT.local, SAN DNS=MaraHomeNew.PEACEFULSPIRIT.local, valid to 5/10/2027
  • "Peaceful Spirit VPN" AllUserConnection: AuthenticationMethod MachineCertificate, confirmed working via rasdial

DESKTOP-0O8A1RL

  • ~/.ssh/known_hosts: stale 192.168.0.2 entries cleared; new ED25519 host key for PST-SERVER accepted

Credentials & Secrets

Item Value
PST-SERVER SSH sysadmin@192.168.0.2, key: ~/.ssh/id_ed25519 (DESKTOP-0O8A1RL)
PST-SERVER domain admin PEACEFULSPIRIT\sysadmin / r3tr0gradE99!
PFX password (HP + Surface) PstVpn2026!
VPN credential PEACEFULSPIRIT\pst-admin / 24Hearts$
UCG SSH key ~/.ssh/pst-cc-ucg / Gptf*77ttb123!@#

Infrastructure & Servers

Component Value
PST-SERVER SSH port 22, key auth from DESKTOP-0O8A1RL (requires OpenVPN to PST-CC active)
PST-SERVER OpenSSH path C:\Program Files\OpenSSH\OpenSSH-Win64\
Machine template NameFlag 0x1 (ENROLLEE_SUPPLIES_SUBJECT) — changed this session
RRAS UserAuthProtocolAccepted EAP, MsChapv2, Certificate
MaraHomeNew cert D067E07B (CN=MaraHomeNew.PEACEFULSPIRIT.local, to 5/10/2027)
Maras-HP-Laptop cert 4CADDE8F (CA RequestId 66) — PFX on PST-SERVER + local Temp
PST-SURFACE cert 197FF22A (CA RequestId 67) — PFX on PST-SERVER + local Temp
PFX local copies C:\Users\guru\AppData\Local\Temp\Maras-HP-Laptop.pfx, PST-SURFACE.pfx

Commands & Outputs

Fix Machine template Subject Name source (PST-SERVER as sysadmin)

$t = [ADSI]"LDAP://CN=Machine,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=PEACEFULSPIRIT,DC=local"
$t.Properties["msPKI-Certificate-Name-Flag"].Value = 1
$t.CommitChanges()
# Returns 1 — confirmed

Reissue cert for MaraHomeNew

# On MaraHomeNew
certreq -new C:\Windows\Temp\machine2.inf C:\Windows\Temp\machine2.req
scp C:\Windows\Temp\machine2.req sysadmin@192.168.0.2:/C:/ProgramData/machine2.req
# On PST-SERVER
certreq -submit -config "PST-SERVER.PEACEFULSPIRIT.local\PEACEFULSPIRIT-PST-SERVER-CA" C:\ProgramData\machine2.req C:\ProgramData\machine2.cer
# Back on MaraHomeNew
scp sysadmin@192.168.0.2:/C:/ProgramData/machine2.cer C:\Windows\Temp\machine2.cer
certreq -accept C:\Windows\Temp\machine2.cer
# Result: D067E07B4A670AF5C6DE27250EB533B06F28FD6A

Add Certificate to RRAS auth (PST-SERVER via SSH)

Set-VpnAuthProtocol -UserAuthProtocolAccepted EAP, MsChapv2, Certificate
Restart-Service RemoteAccess
# Valid enum: EAP, Certificate, MsChapv2, Chap, PAP, PreSharedKey

VPN test result

rasdial "Peaceful Spirit VPN"
Connecting to Peaceful Spirit VPN...
[SUCCESS]

Win32-OpenSSH install on PST-SERVER

& "C:\Program Files\OpenSSH\OpenSSH-Win64\install-sshd.ps1"
Start-Service sshd; Set-Service sshd -StartupType Automatic
netsh advfirewall firewall add rule name="OpenSSH" dir=in action=allow protocol=TCP localport=22

SSH from DESKTOP-0O8A1RL (requires OpenVPN active)

ssh -i ~/.ssh/id_ed25519 sysadmin@192.168.0.2

PFX deployment command (target machine, run as admin)

Import-PfxCertificate -FilePath .\MachineName.pfx -CertStoreLocation Cert:\LocalMachine\My -Password (ConvertTo-SecureString "PstVpn2026!" -AsPlainText -Force)
Add-VpnConnection -Name "Peaceful Spirit VPN" -ServerAddress "98.190.129.150" -TunnelType IKEv2 -AuthenticationMethod MachineCertificate -AllUserConnection -SplitTunneling -Force

Pending / Incomplete Tasks

Task Status Notes
Deploy cert + VPN to Maras-HP-Laptop via RMM PENDING PFX at C:\Users\guru\AppData\Local\Temp\Maras-HP-Laptop.pfx. RMM agent: 13cb3629
Deploy cert + VPN to PST-SURFACE via RMM PENDING PFX at C:\Users\guru\AppData\Local\Temp\PST-SURFACE.pfx. RMM agent: 4a993b61
Test pre-login VPN on all 3 machines PENDING MaraHomeNew rasdial confirmed. HP and Surface pending cert deployment.
Test VPN at Windows login screen (pre-login) PENDING rasdial works in user session. Need to verify AllUserConnection triggers at logon screen.
Clean up temp files on PST-SERVER PENDING C:\ProgramData: fix_acl.ps1, acl_result.txt, verify_acl.ps1, gen_certs.ps1, *.inf, *.req, *.cer, *.pfx, diag_out.txt
Remove TEMP firewall rules on PST-SERVER PENDING TEMP-CertEnroll-RPC (TCP 135) and TEMP-CertEnroll-DCOM (TCP 49152-65535) from prior session
Identify OpenVPN Connect profiles on HP/Surface PENDING OpenVPN Connect running (4 procs each) but no .ovpn files in standard paths

Reference Information

  • PST-SERVER SSH: ssh -i ~/.ssh/id_ed25519 sysadmin@192.168.0.2 (OpenVPN to PST-CC required)
  • PFX deploy one-liner: Import-PfxCertificate + Add-VpnConnection (see Commands section)
  • RMM agents: MaraHomeNew c778b6a3, Maras-HP-Laptop 13cb3629, PST-SURFACE 4a993b61, PST-SERVER 6b6106a7
  • SCP to/from PST-SERVER: use /C:/path/to/file format (not C:\)
  • gen_certs.ps1 at C:\ProgramData\gen_certs.ps1 on PST-SERVER — reusable for future machines
  • Machine template NameFlag GUID reference: ENROLLEE_SUPPLIES_SUBJECT = 0x1, prior value 0x18000000 (DNS_AS_CN | ALT_REQUIRE_DNS)

Update: 18:18 PT — OneDrive KFM shell folder deep fix

User

  • User: Mike Swanson (mike)
  • Machine: DESKTOP-0O8A1RL
  • Role: admin
  • Session span: 2026-05-11 afternoon continuation

Session Summary

Troubleshooting of the OneDrive KFM "Capabilities: 0x101" error for user pst-admin on Maras-HP-Laptop resumed. The user provided a screenshot showing three GUID entries in HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders still pointing to \PST-SERVER. These GUIDs were not covered by prior fix scripts, which only targeted standard KF GUIDs. A new script, fix_remaining_folders.ps1, was written and deployed to update the three GUIDs to local userprofile paths, clear remaining FolderRedirectionPolicyValue markers, and remove Folder Redirection CSE history from Group Policy\History. The user ran the script, but the error remained.

A full registry diagnostic via GuruRMM API was initiated against the HP, accessing pst-admin's hive via HKU\S-1-5-21-1105246401-3156558273-4088333098-1118. The diagnostic revealed two WSE-specific non-standard GUID entries in User Shell Folders still pointing to the server, and a stale Shell Folders resolved cache that still showed all original \PST-SERVER paths for every redirected folder. The Shell Folders key is what the shell and OneDrive actually read at runtime; it had not been rebuilt because pst-admin had not logged off/on since the prior fix ran.

A second script, hp_final_fix.ps1, was deployed via RMM running as SYSTEM against the HKU hive. It corrected the two non-standard WSE GUIDs in User Shell Folders and directly updated all 10 server-pointing Shell Folders entries to local C:\Users\pst-admin... paths. Verification confirmed zero remaining \PST-SERVER entries in either key. The fix is complete in the registry; pst-admin must log off and back on for the live session to reflect the corrected state.

Key Decisions

  • Targeted WSE non-standard GUIDs after discovering they differ from standard KF GUIDs: WSE wrote its own GUID variants alongside the standard ones; prior scripts only addressed the standard GUIDs.
  • Deployed the final fix via RMM as SYSTEM against the HKU hive: allows both User Shell Folders and Shell Folders to be corrected in one pass regardless of what pst-admin was doing.
  • Directly updated Shell Folders (the resolved cache) in addition to User Shell Folders: the cache had not been rebuilt at logon because prior fixes ran while pst-admin was still logged in; direct correction ensures the fix is visible immediately after the next logoff/on.
  • Used /api/auth/login endpoint instead of raw JWT: raw HS256 JWT generation returned 401 despite correct secret; session token from login endpoint worked.

Problems Encountered

  • fix_remaining_folders.ps1 did not resolve error: Script ran and cleared markers/CSE history, but error remained. Root cause: stale Shell Folders resolved cache and two additional WSE-specific GUIDs not targeted by the script.
  • JWT auth returning 401: Raw HS256 JWT (manually constructed) rejected by RMM API despite correct secret and algorithm. Resolved by using /api/auth/login with admin credentials to obtain session token.
  • Wrong RMM result endpoint: Initial poll used /api/agents/{id}/command/{cmdId} (404). Correct endpoint: /api/commands/{cmdId}.
  • ConvertTo-Json nesting PS script body: PowerShell hashtable caused ConvertTo-Json to emit nested map; API expected plain string for command field. Resolved by using py to JSON-encode the script file.
  • WSE non-standard GUIDs: WSE GPO wrote two non-standard GUID variants in User Shell Folders alongside standard KF GUIDs. Standard: {4C5C32FF-BB9D-4518-B176-DEC04FF96F7E} / {BFB9D5E0-C6A9-4D9F-9667-1F64AD761B0C}. WSE variants: {4C5C32FF-BB9D-43B0-B5B4-2D72E54EAAA4} / {BFB9D5E0-C6A9-404C-B2B2-AE6DB6AF4968}. Both sets had to be fixed.
  • Shell Folders not rebuilt at logon: Cache still contained server paths after User Shell Folders was fixed, because pst-admin had not logged off/on since the prior fix. Resolved by directly updating Shell Folders via RMM.

Configuration Changes

Maras-HP-Laptop (pst-admin HKCU, applied via SYSTEM/HKU)

  • HKCU\...\Explorer\User Shell Folders:
    • {4C5C32FF-BB9D-43B0-B5B4-2D72E54EAAA4} set to C:\Users\pst-admin\Saved Games (was \PST-SERVER...SavedGames)
    • {BFB9D5E0-C6A9-404C-B2B2-AE6DB6AF4968} set to C:\Users\pst-admin\Links (was \PST-SERVER...Links)
    • fix_remaining_folders.ps1 earlier fixed: {4C5C32FF-BB9D-4518-B176-DEC04FF96F7E}, {56784854-C6CB-462B-8169-88E350ACB882}, {BFB9D5E0-C6A9-4D9F-9667-1F64AD761B0C}
  • HKCU\...\Explorer\Shell Folders: 10 entries corrected from \PST-SERVER to C:\Users\pst-admin... (Desktop, Personal, My Pictures, My Video, My Music, Favorites, {374DE290}/Downloads, {56784854}/Contacts, {BFB9D5E0-404C}/Links, {4C5C32FF-43B0}/SavedGames)

Scripts written (DESKTOP-0O8A1RL)

  • C:\Users\guru\Desktop\fix_remaining_folders.ps1 — 3 standard GUIDs + CSE cleanup
  • C:\Users\guru\AppData\Local\Temp\hp_reg_diag.ps1 — diagnostic via RMM/HKU
  • C:\Users\guru\AppData\Local\Temp\hp_final_fix.ps1 — 2 WSE GUIDs + Shell Folders

Credentials & Secrets

Item Value
GuruRMM API login claude-api@azcomputerguru.com / ClaudeAPI2026!@#
GuruRMM JWT secret ZNzGxghru2XUdBVlaf2G2L1YUBVcl5xH0lr/Gpf/QmE= (vault: infrastructure/gururmm-server.sops.yaml)
pst-admin password SpiritWalk26! (update vault)

Infrastructure & Servers

Component Value
GuruRMM API external https://rmm.azcomputerguru.com
GuruRMM API internal http://172.16.3.30:3001
RMM auth endpoint POST /api/auth/login
RMM command submit POST /api/agents/{uuid}/command
RMM command result GET /api/commands/{cmdId}
HP RMM agent UUID 13cb3629-5043-4bd6-b977-6968eeccf804
pst-admin SID S-1-5-21-1105246401-3156558273-4088333098-1118

Commands & Outputs

RMM auth + command submit (correct pattern)

$auth = Invoke-RestMethod -Uri "https://rmm.azcomputerguru.com/api/auth/login" -Method POST -ContentType "application/json" -Body (@{ email = "claude-api@azcomputerguru.com"; password = "ClaudeAPI2026!@#" } | ConvertTo-Json)
$token = $auth.token
$payload = py -c "import json; print(json.dumps({'command_type':'powershell','command':open(r'C:\path\to\script.ps1',encoding='utf-8').read()}))"
$resp = Invoke-RestMethod -Uri "https://rmm.azcomputerguru.com/api/agents/$agent/command" -Method POST -Headers @{ Authorization = "Bearer $token"; "Content-Type" = "application/json" } -Body $payload
# Poll result: GET /api/commands/{cmdId} — output in .stdout field

hp_final_fix.ps1 verification output

=== Verification: any remaining server paths? ===
=== Done - pst-admin must log off and back on ===
# (no lines output = zero remaining server paths confirmed)

Pending / Incomplete Tasks

Task Status Notes
Test OneDrive KFM after pst-admin logoff/on PENDING Registry fully clean; logoff/on required to rebuild live session Shell Folders
Update vault with pst-admin new password PENDING SpiritWalk26!
Deploy cert + VPN to Maras-HP-Laptop via RMM PENDING PFX: C:\Users\guru\AppData\Local\Temp\Maras-HP-Laptop.pfx; agent 13cb3629-5043-4bd6-b977-6968eeccf804
Deploy cert + VPN to PST-SURFACE via RMM PENDING PFX: C:\Users\guru\AppData\Local\Temp\PST-SURFACE.pfx; agent 4a993b61-59b3-42f4-bdb5-d4362941f7d6
Test pre-login VPN at Windows logon screen PENDING rasdial confirmed in user session only
Browser default (http/https) for pst-admin PENDING Must click "Make Chrome default" in Chrome once
Clean up PST-SERVER temp files PENDING C:\ProgramData: gen_certs.ps1, *.inf, *.req, *.cer, *.pfx, misc .ps1s
Remove TEMP firewall rules on PST-SERVER PENDING TEMP-CertEnroll-RPC (TCP 135), TEMP-CertEnroll-DCOM (TCP 49152-65535)

Reference Information

  • WSE non-standard GUIDs vs standard KF GUIDs:
    • SavedGames — WSE: {4C5C32FF-BB9D-43B0-B5B4-2D72E54EAAA4} | Standard: {4C5C32FF-BB9D-4518-B176-DEC04FF96F7E}
    • Links — WSE: {BFB9D5E0-C6A9-404C-B2B2-AE6DB6AF4968} | Standard: {BFB9D5E0-C6A9-4D9F-9667-1F64AD761B0C}
  • Shell Folders (HKCU...\Explorer\Shell Folders) = resolved runtime cache; User Shell Folders = template. Both must be clean for OneDrive KFM.
  • All FolderRedirectionPolicyValue* markers: NONE confirmed
  • Folder Redirection CSE history ({25537BA6}): NONE confirmed
  • OneDrive HKCU/HKLM policies: NONE
  • DisablePersonalDirChange: NOT SET

Update: 19:11 PT — Root cause: SHSetKnownFolderPath flags bug

User

  • User: Mike Swanson (mike)
  • Machine: DESKTOP-0O8A1RL
  • Role: admin
  • Session span: 2026-05-11 evening continuation

Session Summary

After reboot, a post-reboot registry diagnostic via RMM confirmed that USF and SF registry entries showed all local paths with no redirection markers or CSE history, indicating a clean registry state. Despite this, the Location tab for Documents, Desktop, and Pictures remained greyed, prompting further investigation. A OneDrive-specific diagnostic confirmed no policies were set in HKLM or HKCU, and OneDrive was using a personal account with valid registry entries. However, attempts to access ClientPolicy.ini files via PowerShell hung due to an exclusive lock held by OneDrive. A profile type check confirmed the pst-admin profile was local, eliminating roaming profile reapplication as a potential cause.

Further checks of desktop.ini files, CLSID overrides, ntuser.pol, and FolderDescriptions found no redirection markers or anomalous settings. The root cause was identified: prior scripts had been calling SHSetKnownFolderPath with flags=0x4000 (KF_FLAG_DONT_VERIFY), which is only valid for the GET call. Per MSDN, SHSetKnownFolderPath requires flags=0 (reserved). All SET calls across all prior script iterations had been returning 0x80070057 (E_INVALIDARG) silently — the shell's internal Known Folder state was never updated. The registry was correct from our direct HKU edits, but the shell's in-process known folder infrastructure still showed the folders as policy-managed.

A corrected script, reset_kf_final.ps1, was written with flags=0 for SHSetKnownFolderPath. When run in pst-admin's session context, it will properly update the shell's Known Folder state, which is what controls both the Location tab editability and OneDrive's KFM eligibility check.

Key Decisions

  • Eliminated roaming profile as cause by checking HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\{SID} — ProfileImagePath=C:\Users\pst-admin, Flags=0, confirming local profile.
  • Investigated ClientPolicy.ini lock rather than assuming it contained a blocking entry — the file was inaccessible due to OneDrive holding an exclusive lock; HKLM/HKCU OneDrive policy paths confirmed NONE.
  • Identified the correct diagnostic gap: all prior SHSetKnownFolderPath calls failed silently with E_INVALIDARG due to invalid flags=0x4000; the registry workaround (HKU direct writes) was correct for data but bypassed the shell API layer that maintains known folder state.
  • Chose to write a new script (reset_kf_final.ps1) rather than patch existing ones, ensuring the API call is correct before the next pst-admin session.

Problems Encountered

  • ClientPolicy.ini reads hung: Get-Content and FileShare.ReadWrite both blocked because OneDrive held an exclusive lock on the settings .ini files. Deferred; HKLM/HKCU policy paths confirmed NONE, so lock contents were not blocking KFM from the policy path.
  • Location tab still greyed post-reboot despite clean registry: Root cause: SHSetKnownFolderPath was called with flags=0x4000 in every prior script iteration. The SET function rejects any non-zero flags with E_INVALIDARG. This caused the shell to never update its internal known folder state. Our direct HKU registry writes were correct for the data layer but the shell's known folder infrastructure reads its own internal state (not just the registry) to determine policy-management status.
  • RMM commands hanging on file reads: Several diagnostic scripts hung when attempting to read OneDrive settings files or use SHGetKnownFolderPath P/Invoke from SYSTEM context. Mitigated by isolating commands to simple registry reads and cmd-based file access; P/Invoke shell API calls from SYSTEM context are not safe.

Configuration Changes

Scripts written (DESKTOP-0O8A1RL)

  • C:\Users\guru\Desktop\reset_kf_final.ps1 — corrected SHSetKnownFolderPath with flags=0; run as pst-admin to update shell Known Folder state

No registry changes this segment

Registry was confirmed clean from previous segment. No further writes made.

Credentials & Secrets

No new credentials this segment.

Infrastructure & Servers

Component Value
HP RMM agent UUID 13cb3629-5043-4bd6-b977-6968eeccf804
pst-admin SID S-1-5-21-1105246401-3156558273-4088333098-1118
pst-admin profile type LOCAL (C:\Users\pst-admin, Flags=0, not roaming)
OneDrive account Personal — mara.concordia@gmail.com (cid: 25f0851177ceabfd)
OneDrive version 26.070.0414.0001

Commands & Outputs

Post-reboot registry state (confirmed clean via RMM)

USF server paths: NONE - all local
SF server paths:  NONE - all local
FolderRedirectionPolicyValue markers: NONE
CSE history (25537BA6): NONE
OneDrive HKCU/HKLM policies: NONE

SHSetKnownFolderPath bug — prior vs corrected

# WRONG (all prior scripts) — flags=0x4000 is GET-only, causes E_INVALIDARG on SET
$hr = [KFHelper]::SHSetKnownFolderPath([ref]$guid, [uint32]0x4000, [IntPtr]::Zero, $path)
# Result: HRESULT=0x80070057 (E_INVALIDARG) for every folder

# CORRECT (reset_kf_final.ps1)
$hr = [KFHelper2]::SHSetKnownFolderPath([ref]$guid, 0, [IntPtr]::Zero, $path)
# flags MUST be 0 per MSDN ("reserved, must be 0")

pst-admin profile check

ProfileImagePath : C:\Users\pst-admin
Flags            : 0
FullProfile      : 1
State            : 0
# No CentralProfile, no UNC path → confirmed LOCAL profile

Desktop.ini checks

Documents\desktop.ini : NOT FOUND
Desktop\desktop.ini   : NOT FOUND
Pictures\desktop.ini  : standard ShellClassInfo/icon entries only — no redirection markers
ntuser.pol            : NOT FOUND
CLSID overrides (HKCU) for Documents/Desktop/Pictures: none

Pending / Incomplete Tasks

Task Status Notes
Run reset_kf_final.ps1 as pst-admin + logoff/on PENDING Script at C:\Users\guru\Desktop\reset_kf_final.ps1; must run non-elevated as pst-admin
Test OneDrive KFM after reset_kf_final + logoff/on PENDING If SET calls return OK, Location tab should unlock and KFM should work
Update vault with pst-admin new password PENDING SpiritWalk26!
Deploy cert + VPN to Maras-HP-Laptop via RMM PENDING PFX: C:\Users\guru\AppData\Local\Temp\Maras-HP-Laptop.pfx; agent 13cb3629-5043-4bd6-b977-6968eeccf804
Deploy cert + VPN to PST-SURFACE via RMM PENDING PFX: C:\Users\guru\AppData\Local\Temp\PST-SURFACE.pfx; agent 4a993b61-59b3-42f4-bdb5-d4362941f7d6
Test pre-login VPN at Windows logon screen PENDING
Browser default (http/https) for pst-admin PENDING Must click "Make Chrome default" in Chrome once
Clean up PST-SERVER temp files PENDING C:\ProgramData: gen_certs.ps1, *.inf, *.req, *.cer, *.pfx, misc .ps1s
Remove TEMP firewall rules on PST-SERVER PENDING TEMP-CertEnroll-RPC (TCP 135), TEMP-CertEnroll-DCOM (TCP 49152-65535)

Reference Information

  • MSDN: SHSetKnownFolderPath — dwFlags is reserved, must be 0. flags=0x4000 (KF_FLAG_DONT_VERIFY) is only valid for SHGetKnownFolderPath.
  • Known Folder GUIDs used in reset_kf_final.ps1: Documents FDD39AD0, Desktop B4BFCC3A, Pictures 33E28130, Music 4BD8D571, Videos 18989B1D, Downloads 374DE290, Favorites 1777F761, Links BFB9D5E0, Contacts 56784854
  • OneDrive settings path: C:\Users\pst-admin\AppData\Local\Microsoft\OneDrive\settings\Personal\ — ClientPolicy.ini locked by OneDrive process; use FileShare.ReadWrite or robocopy /B if needed
  • RMM result endpoint: GET /api/commands/{cmdId} (not /api/agents/{id}/command/{cmdId})
  • SHGetKnownFolderPath / SHSetKnownFolderPath P/Invoke hangs when called from SYSTEM context — only use in user-context scripts

Update: 19:42 PT — Profile wipe, per-machine OneDrive, Block New Outlook GPO

User

  • User: Mike Swanson (mike)
  • Machine: DESKTOP-0O8A1RL
  • Role: admin
  • Session span: 2026-05-11 evening continuation

Session Summary

The session began with the execution of reset_kf_final.ps1 as pst-admin to address the persistent OneDrive KFM error. Despite the corrected SHSetKnownFolderPath flags=0 call, the known folder policy-managed state remained unchanged and the same error persisted. A decision was made to wipe the pst-admin user profile entirely. A WMI-based profile deletion was submitted via RMM, successfully removing the profile folder, ProfileList registry entry, and all associated state.

Following the profile wipe, a per-machine OneDrive installation was deployed via RMM using OneDriveSetup.exe /allusers /silent. This installs to C:\Program Files\Microsoft OneDrive and makes OneDrive available to all users without requiring per-user bootstrap, replacing the prior per-user install that was destroyed with the profile.

A GPO named "Block New Outlook" was created on PST-SERVER and linked to the domain root to prevent the new Outlook experience from appearing across all domain machines. The GPO included a registry preference to disable the toggle in classic Outlook 365, a PowerShell startup script in SYSVOL to remove the Microsoft.OutlookForWindows AppX package for all users, and policy-based PowerShell execution settings to ensure the script runs.

Key Decisions

  • Wipe pst-admin profile entirely rather than continue debugging known folder state: After reset_kf_final.ps1 with the corrected flags=0 still failed to clear the policy-managed state, a full profile reset was the cleanest path. All prior session's registry work had confirmed no policy sources; the residual state was inside the shell's in-process known folder infrastructure with no clean API path to reset it from SYSTEM context.
  • Deploy per-machine OneDrive (/allusers) rather than per-user: Ensures OneDrive is present at C:\Program Files\Microsoft OneDrive for all users without requiring a per-user install to run at first logon. Avoids the bootstrapping problem where pst-admin's fresh profile would have no OneDrive until the per-user installer triggered.
  • GPO at domain root rather than Workstations OU: Applied to all domain computers per user request. Server exclusion not required in this environment.

Problems Encountered

  • reset_kf_final.ps1 (flags=0) did not resolve KFM error: Ran in pst-admin session context with correct flags; error persisted. Root cause likely that the shell's known folder infrastructure had additional state beyond what SHSetKnownFolderPath alone can clear after an extended policy-redirection history. Resolved by full profile wipe.

Configuration Changes

GPO created (PST-SERVER / PEACEFULSPIRIT.local)

  • GPO: Block New Outlook — GUID {577028AF-0901-4BDF-A283-CD1156F313D9}
  • Linked to: DC=PEACEFULSPIRIT,DC=local (all computers, link enabled)
  • Registry: HKLM\SOFTWARE\Policies\Microsoft\Office\16.0\Outlook\EnableNewOutlook = 0
  • SYSVOL script: {577028AF-...}\Machine\Scripts\Startup\Remove-NewOutlook.ps1
  • SYSVOL ini: {577028AF-...}\Machine\Scripts\psscripts.ini
  • Policy: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\EnableScripts = 1, ExecutionPolicy = RemoteSigned

OneDrive installed per-machine (Maras-HP-Laptop)

  • C:\Program Files\Microsoft OneDrive\OneDrive.exe version 26.063.0405.0002

pst-admin profile wiped (Maras-HP-Laptop)

  • C:\Users\pst-admin — deleted via WMI Win32_UserProfile.Delete()
  • HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-1105246401-3156558273-4088333098-1118 — removed

Scripts written (DESKTOP-0O8A1RL)

  • C:\Users\guru\AppData\Local\Temp\hp_delete_profile.ps1 — WMI profile delete
  • C:\Users\guru\AppData\Local\Temp\hp_install_onedrive_allusers.ps1 — per-machine OneDrive deploy
  • C:\Users\guru\AppData\Local\Temp\pst_create_gpo_no_new_outlook.ps1 — GPO creation

Credentials & Secrets

No new credentials this segment.

Infrastructure & Servers

Component Value
Maras-HP-Laptop RMM agent 13cb3629-5043-4bd6-b977-6968eeccf804
PST-SERVER RMM agent 6b6106a7-8515-4b6b-857d-0dc6ede53f35
PST-SURFACE RMM agent 4a993b61-59b3-42f4-bdb5-d4362941f7d6
pst-admin SID S-1-5-21-1105246401-3156558273-4088333098-1118
OneDrive version (per-machine) 26.063.0405.0002
Block New Outlook GPO GUID {577028AF-0901-4BDF-A283-CD1156F313D9}

Commands & Outputs

pst-admin profile delete via WMI (RMM → Maras-HP-Laptop)

Found profile: C:\Users\pst-admin  Loaded: False
Profile deleted via WMI.
ProfileList key removed — clean.
C:\Users\pst-admin folder gone.

OneDrive per-machine install (RMM → Maras-HP-Laptop)

Downloaded: 105677672 bytes
Exit code: 0
Installed: C:\Program Files\Microsoft OneDrive\OneDrive.exe  version=26.063.0405.0002

GPO creation (RMM → PST-SERVER)

Created GPO: Block New Outlook  GUID={577028AF-0901-4BDF-A283-CD1156F313D9}
Linked to domain root.
Set: HKLM\SOFTWARE\Policies\Microsoft\Office\16.0\Outlook\EnableNewOutlook = 0
Startup script written: ...\Startup\Remove-NewOutlook.ps1
psscripts.ini written: ...\Machine\Scripts\psscripts.ini
Link verified: enabled=True

RMM command_type fix

# API now requires command_type field — was missing in prior sessions
# Valid values: powershell, shell, python, script
body = {'command_type': 'powershell', 'command': <script>, 'timeout': 120}
POST /api/agents/{uuid}/command

Pending / Incomplete Tasks

Task Status Notes
pst-admin login + OneDrive KFM setup PENDING Fresh profile; per-machine OneDrive installed; sign in with mara.concordia@gmail.com, enable folder backup
Update vault with pst-admin new password PENDING SpiritWalk26!
Deploy cert + VPN to Maras-HP-Laptop via RMM PENDING PFX: C:\Users\guru\AppData\Local\Temp\Maras-HP-Laptop.pfx; agent 13cb3629
Deploy cert + VPN to PST-SURFACE via RMM PENDING PFX: C:\Users\guru\AppData\Local\Temp\PST-SURFACE.pfx; agent 4a993b61
Test pre-login VPN at Windows logon screen PENDING
Browser default (http/https) for pst-admin PENDING Click "Make Chrome default" in Chrome once after first login
Clean up PST-SERVER temp files PENDING C:\ProgramData: gen_certs.ps1, *.inf, *.req, *.cer, *.pfx
Remove TEMP firewall rules on PST-SERVER PENDING TEMP-CertEnroll-RPC (TCP 135), TEMP-CertEnroll-DCOM (TCP 49152-65535)
Verify Block New Outlook GPO on workstations PENDING gpupdate /force on HP after pst-admin logs in; reboot to trigger AppX removal script

Reference Information

  • GuruRMM command submit: POST /api/agents/{uuid}/command — body requires command_type field (powershell/shell/python/script); was missing in prior sessions, caused 422
  • GuruRMM result poll: GET /api/commands/{cmd_id} — output in .stdout field
  • Block New Outlook GPO GUID: {577028AF-0901-4BDF-A283-CD1156F313D9}
  • SYSVOL path: C:\Windows\SYSVOL\sysvol\PEACEFULSPIRIT.local\Policies\{577028AF-0901-4BDF-A283-CD1156F313D9}\
  • PowerShell startup scripts registered via psscripts.ini (Unicode/UTF-16 LE), not scripts.ini
  • OneDrive per-machine install: OneDriveSetup.exe /allusers /silent → C:\Program Files\Microsoft OneDrive
Reference in New Issue View Git Blame Copy Permalink