Why it Happens

• Group Policy Bloat: The client machine belongs to an Active Directory domain with heavily customized or deeply nested Group Policy Objects (GPOs).
• MaxEnvelopeSizeKB Limit: WinRM has a default data transfer size limit (typically 500 KB). When a user connects, the target machine evaluates the user's group memberships and policies. If this security context data is too large, the WinRM service fails to parse the WS-Policy structure.
• MaxTokenSize Issue: The Kerberos authentication token is too large due to the user belonging to a massive number of Active Directory groups.

Step-by-Step Fixes

Follow these solutions in order from the quickest local fix to the domain-level fix.

Solution 1: Increase the WinRM Maximum Envelope Size

You need to tell the WinRM service to allow larger data packets so it can process the complex policy structure.

1. Click the Start Menu, type cmd, right-click Command Prompt, and select Run as administrator.
2. Type the following command to check your current envelope size:

   winrm get winrm/config

3. Look for the MaxEnvelopeSizeKB value (the default is usually 500).
4. Run this command to increase the limit to 8000 KB (8 MB) on both the source and destination machines:

   winrm set winrm/config @{MaxEnvelopeSizeKB="8000"}

5. Restart the WinRM service to apply changes:

   net stop winrm && net start winrm

Solution 2: Increase MaxTokenSize via Windows Registry

If the user account running the command belongs to many security groups, the Kerberos token becomes too large for WinRM to handle.

1. Press Windows Key + R, type regedit, and hit Enter to open the Registry Editor.
2. Navigate to the following path: HKEY LOCAL MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters (Note: If the Parameters key does not exist, right-click Kerberos, select New > Key, and name it Parameters)
3. Right-click inside the right pane, select New > DWORD (32-bit) Value.
4. Name the new value MaxTokenSize.
5. Double-click MaxTokenSize, change the Base to Decimal, and set the Value data to 65535.
6. Click OK and restart your computer.

Solution 3: Use Local Accounts to Bypass Domain GPO Complexity

If you are doing basic administrative tasks and cannot change domain-wide GPOs, using a local administrator account instead of a domain account bypasses the complex WS-Policy processing entirely.

1. Open your PowerShell console.
2. Modify your connection string to explicitly pass the local administrator credentials of the destination computer:

   \$cred = Get-Credential
   Enter-PSSession -ComputerName "Target IP Or Name" -Credential \$cred -Authentication Negotiate

3. Provide the username in the format: TargetComputerName\LocalUsername.

Solution 4: Clean Up Active Directory Group Policies (For Domain Admins)

If you are an IT administrator and multiple users face this issue, the root cause is GPO fragmentation.

1. Open the Group Policy Management Console (GPMC) on your Domain Controller.
2. Audit the policies applied to the affected organizational unit (OU).
3. Consolidate multiple small GPOs into single, well-structured GPOs.
4. Remove outdated or redundant policy definitions to shrink the WS-Policy payload delivered to WinRM.