Sysprep fails due to Notepad++ when preparing virtual machine for image capture to deploy Azure Virtual Desktop

One of the common issues I’ve continuously come across while preparing Windows 10 and Windows 2016 above operating systems for virtual desktops or remote desktop services is when sysprep fails due to an installed application linked to a user account. I ran encountered this issue again last month with the application Notepad++ when preparing a Windows 11 Enterprise Multi-Session virtual machine for an Azure Virtual Desktop deployment. There are plenty of different PowerShell cmdlets that can be run in an attempt to fix the issue, but I find some of them result with rendering the virtual machine in a state that I would no longer be confident in deploying so I wanted to some of the steps I use for personal reference and to help anyone who may encounter a similar issue.

Problem

You attempt to run sysprep after finishing the preparation of a master image:

Sysprep immediately fails with the error:

Sysprep was not able to validate your Windows installation.
Review the log file at
%WINDIR%\System32\Sysprep\Panther\setupact.log for
details. After resolving the issue, use Sysprep to validate your installation again.

Opening the setupact.log will reveal the following line:

Error                 SYSPRP Package NotepadPlusPlus_1.0.0.0_neutral__7njy0v32s6xk6 was installed for a user, but not provisioned for all users. This package will not function properly in the sysprep image.

Opening the setuperr.log will reveal the following lines:

2023-05-05 07:20:10, Error                 SYSPRP BCD: BiUpdateEfiEntry failed c000000d

2023-05-05 07:20:10, Error                 SYSPRP BCD: BiExportBcdObjects failed c000000d

2023-05-05 07:20:10, Error                 SYSPRP BCD: BiExportStoreAlterationsToEfi failed c000000d

2023-05-05 07:20:10, Error                 SYSPRP BCD: Failed to export alterations to firmware. Status: c000000d

2023-07-07 19:51:46, Error                 SYSPRP Package NotepadPlusPlus_1.0.0.0_neutral__7njy0v32s6xk6 was installed for a user, but not provisioned for all users. This package will not function properly in the sysprep image.

2023-07-07 19:51:46, Error                 SYSPRP Failed to remove apps for the current user: 0x80073cf2.

2023-07-07 19:51:46, Error                 SYSPRP Exit code of RemoveAllApps thread was 0x3cf2.

2023-07-07 19:51:46, Error                 SYSPRP ActionPlatform::LaunchModule: Failure occurred while executing 'SysprepGeneralizeValidate' from C:\Windows\System32\AppxSysprep.dll; dwRet = 0x3cf2

2023-07-07 19:51:46, Error                 SYSPRP SysprepSession::Validate: Error in validating actions from C:\Windows\System32\Sysprep\ActionFiles\Generalize.xml; dwRet = 0x3cf2

2023-07-07 19:51:46, Error                 SYSPRP RunPlatformActions:Failed while validating Sysprep session actions; dwRet = 0x3cf2

2023-07-07 19:51:46, Error      [0x0f0070] SYSPRP RunDlls:An error occurred while running registry sysprep DLLs, halting sysprep execution. dwRet = 0x3cf2

2023-07-07 19:51:46, Error      [0x0f00d8] SYSPRP WinMain:Hit failure while pre-validate sysprep generalize internal providers; hr = 0x80073cf2

Proceeding to uninstall Notepad++ from the image will allow sysprep to run and complete successfully but this means the deployed virtual desktops would need the application installed manually.

Solution

The first step to take for resolving this issue is to restore the virtual machine from a snapshot that had not failed on a sysprep because the sysprep process removes packages from the operating system and there will be times when:

1. After fixing the Notepad++ application, sysprep would fail and error out on other native Microsoft applications
2. You would notice that Notepad is no longer available on the virtual machine
3. Other odd errors would occur

It is better to troubleshoot and perform sysprep on a machine that has no experienced a half executed but failed sysprep.

Once a fresh snapshot is restored, we can now work on determining which accounts Notepad++ is linked to. This can reviewed by starting PowerShell and executing the following cmdlet:

Get-AppxPackage -AllUser | Format-List -Property PackageFullName,PackageUserInformation

The cmdlet above will list all packages installed and this example coincidentally places the Notepad++ package at the end of the output:

If the package in question starts with a letter earlier than M (for Microsoft) and results in being nested within the long output, we can use the following cmdlet to filter the PackageFullName to what is being searched for:

Get-AppxPackage -AllUser | Where-Object {$_.PackageFullName -like "NotepadPlusPlus*"} | Format-List -Property PackageFullName,PackageUserInformation

With the package located identify which accounts are listed to have the application installed. The screenshot above only lists one account but if there are more, the easiest approach is to delete all the accounts and their profiles. If there is only one account listed and it is the built-in administrator account, you won’t be able to delete it because the following error will be displayed when you try to do so:

The following error occurred while attempting to delete the user admin:

Cannot perform this operation on built-in accounts.

To get around this, log in as the account with Notepad++ install linked to, launch PowerShell and execute the following cmdlet:

Remove-AppxPackage -Package <packagefullname>

The following is the cmdlet that is used to remove Notepad++ from the account:

Remove-AppxPackage -Package NotepadPlusPlus_1.0.0.0_neutral__7njy0v32s6xk6

You should no longer find the Notepad++ when executing the following cmdlet:

Get-AppxPackage -AllUser | Where-Object {$_.PackageFullName -like "NotepadPlusPlus*"} | Format-List -Property PackageFullName,PackageUserInformation

Running sysprep should now complete so the virtual machine can be captured to an image for session host deployments.

Releasing NVIDIA RTX Virtual Workstation License(s) on the License Server Manager

One of the frequent questions I’ve been asked in the past for VDI deployments that are accelerated with NVIDIA GPU GRID cards is how we can release assigned licenses to VDIs that no longer exist. Scenarios that can cause this is if a set of virtual desktops were deployed but then had to get redeployed the same evening because of a required change in configuration (I had to do this once when I needed to change the GPU memory allocation for the desktops).

Failure to have sufficient licenses for the VDIs will display the following message upon logging into the virtual desktop:

Failed to acquire NVIDIA license.

Failed to acquire NVIDIA RTX Virtual Workstation license. Click here for more information.

The short answer is that there isn’t a way to do this via the on-premise license server, command line or the NVIDIA Application Hub, and the recommended method is to either reduce the lease time for the license or completely remove all the licenses allocated to the desktops.

The steps to modify the lease time are as follows:

1. Log onto the VDI master image
2. Open the registry editor and browse to HKEY_LOCAL_MACHINE\SOFTWARE\NVIDIA Corporation\Global\GridLicensing
3. Edit the LicenseInterval DWord (REG_DWORD) and configure the interval time that represents how long the license lease is valid for

The integer configured should be within the range 10-10080 that specifies the period of time in minutes for which a license can be borrowed after it is checked out. After this period has elapsed, the client must obtain a new license from the server.
The default is 1440 minutes, which corresponds to a period of 1 day. The value can be reduce to an hour so a new license would be reissued.

The environment I was working with already had the lease time configured to be a day (default) and further reducing it was not ideal in case we ever had a license server failure so I opted to use the 2^nd method, which was to completely remove all the licenses allocated to the desktops so new ones would be issued. It is worth noting that I was told by the NVIDIA support engineer that this does not adversely affect the VDIs currently in use so it can be performed during regular hours.

The following are the steps:

1. Begin by logging into the NVIDIA Application Hub via the URL: https://nvid.nvidia.com/dashboard/

2. Select NVIDIA LICENSING PORTAL:

3. Navigate to LICENSE SERVERS, expand the License Server node and click on Download:

4. The license file representing the licenses will be downloaded:

5. On the on-premise NVIDIA licensing server, stop FlexNet License Server - nvidia service:

6. Navigate to the path: C:\Windows\ServiceProfiles\NetworkService\flexnetls\:

7. Rename the nvidia folder to nvidia-old:

8. Start FlexNet License Server - nvidia service:

9. Open the license portal on the on-premise NVIDIA license server, navigate to License Management, ensure that the server is up, and the following error message is NOT present:

Connection error: Please make sure the FNE server is up and running

10. Confirm that the nvidia folder previously renamed has been recreated:

11. Confirm that there are no licensed clients listed:

12. With the server services up, proceed to upload the previously downloaded license file (.bin):

13. Confirm that the message Successfully applied license file to the license server. is displayed:

14. Navigating back to the Licensed Clients window should initially show an empty list and then new clients being listed:

Enable Security Authentication for NVIDIA License Server Manager

Those who have worked with the NVIDIA License Server Manager that is deployed to provide virtual desktops with GPU licenses will quickly notice that the default install does not provide any security for the management console as navigating to the URL: http://localhost:8080/licserver/ will bring you straight into the console without authentication. Given that I’ve been asked many times in the past about securing this portal, this post serves to demonstrate the process.

Enabling the requirement for logging in as shown in the screenshot below cannot be done via the GUI:

To enable the authentication requirement, we’ll need to use the nvidialsadmin.bat via the command line. The nvidialsadmin.bat can be found in the directory C:\NVIDIA\LicenseServer\enterprise on the licensing server:

Enable Security for the NVIDIA License Server Manager

1. Begin by launching a command prompt as an administrator and navigating to the directory: C:\NVIDIA\LicenseServer\enterprise

2. Execute the following command to set the security flag as true:

nvidialsadmin.bat -server http://127.0.0.1:7070 -config -set security.enabled=true

3. Next, execute the following command with the default password for the admin account (Admin@123) and set the new password (Update the New-Password1 value to the password desired):

nvidialsadmin.bat -server http://127.0.0.1:7070 -authorize admin Admin@123 -users -edit admin New-Password1

4. Proceed to restart the Apache Tomcat 9.0 Tomcat9 service in the services console on the license server:

5. Wait for the license server to be fully started then try to navigate to the console at http://localhost:8080/licserver/ to verify that credentials are required:

Disable Security for the NVIDIA License Server Manager

1. To disable the security login requirement execute the following command with the configured password to authorize the session:

nvidialsadmin -server http://127.0.0.1:7070 -authorize admin New-Password1

2. Then set the security flag to false:

nvidialsadmin.bat -server http://127.0.0.1:7070 -authorize admin New-Password -config -set security.enabled=false

3. Proceed to restart the Apache Tomcat 9.0 Tomcat9 service in the services console on the license server:

4. Wait for the license server to be fully started then try to navigate to the console at http://localhost:8080/licserver/ to verify that credentials are no longer required.

Attempting to access Windows Virtual Desktop (WVD) displays the message: “It looks like your system administrator hasn’t set up any resources username@contoso.com yet. Please choose a different account or try again. If you believe you have received this message in error, please contact your system administrator.”

One of the most common problems I find many of my clients and colleagues experience during there first deployment of WVD is that upon completing the configuration of the host pool, application group, and assignment of users, they receive the following message from the both the web client and the Windows desktop client:

It looks like your system administrator hasn’t set up any resources for username@contoso.com yet. Please choose a different account or try again. If you believe you have received this message in error, please contact your system administrator.

Many of the forum posts tend to point the user to ensure they are not using the older non-arm URL for arm deployments:

• https://rdweb.wvd.microsoft.com/arm/webclient (short URL: https://aka.ms/wvdarmweb)
• https://rdweb.wvd.microsoft.com/webclient/index.html (short URL: http://aka.ms/wvdweb)

However, what I’ve found to be the frequent cause is if the administrator either has not created a Workspace or added the Application Group into the Workspace:

Hope this helps anyone who might have missed this step.

Event ID 3001 Error constantly logged on Citrix Cloud Connectors after FortiOS upgrade to 6.2.3 causing virtual desktop connectivity issues

Problem

You’ve just recently upgraded the FortiOS of a FortiGate 600D to version 6.2.3 and began to experience connectivity issues to a Citrix Virtual Apps and Desktops 1909 environment where users are unable to connect to desktops and receive the following error:

Cannot start desktop “Desktop Name”.

Desktops in the Citrix Studio also show that the VDA agents would suddenly become unregistered and later registered again but regardless of their state, brokered sessions fail majority of the time.

Errors on Citrix Cloud Connector Servers

Logging onto the Citrix Cloud Connectors reveal that the following event ID is constantly logged every 5 to 7 minutes:

Log Name: Application

Source: Citrix Remote Broker Provider

Event ID: 3001

Level: Error

User: NETWORK SERVICE

HA Mode Checking Start - component Broker Proxy has reported a failure with reason = Received: HAModeException - No WebSocket channels are available. (Target url: contoso.xendesktop.net/Citrix/XaXdProxy/)

Log Name: Application

Source: Citrix Remote Broker Provider

Event ID: 3001

Level: Error

User: NETWORK SERVICE

HA Mode Checking Start - component XmlServicesPlugin has reported a failure with reason = The underlying connection was closed: An unexpected error occurred on a receive.(Target Url: https://contoso.xendesktop.net/scripts/wpnbr.dll)

Running the Cloud Connector Connectivity Check utility from: https://support.citrix.com/article/CTX260337

Will show inconsistent results where various URLs will fail at different times:

Performing Wireshark on the Citrix Cloud Connectors will reveal that there are a lot of connection resets between the Citrix Cloud and the Cloud Connectors.

A short trace of 229 packets using filter ip.addr eq 20.41.61.15 and tcp.analysis.flags, reveals that 66 packets are TCP retransitions equating to almost 29% with and 12 TCP resets coming from connector.

**Note that the 20.41.61.15 IP resolves to the URL that the Citrix Cloud Connector is having issues connecting to.

Errors on Citrix StoreFront Servers

Logging onto the Citrix StoreFront servers will reveal the following events constantly logged repetitive:

Log Name: Citrix Delivery Services

Source: Citrix Store Service

Event ID: 4011

Level: Information

User: N/A

The Citrix XML Service at address citrixcloud1.contoso.com:80 has passed the background health check and has been restored to the list of active services.

Log Name: Citrix Delivery Services

Source: Citrix Store Service

Event ID: 0

Level: Error

User: N/A

The Citrix servers sent HTTP headers indicating that an error occurred: 500 Internal Server Error. This message was reported from the XML Service at address http://citrixcloud2.contoso.com/scripts/wpnbr.dll [NFuseProtocol.TRequestAddress]. The specified Citrix XML Service could not be contacted and has been temporarily removed from the list of active services.

**The above error will cycle through all of the Citrix Cloud Connectors.

Log Name: Citrix Delivery Services

Source: Citrix Store Service

Event ID: 4003

Level: Error

User: N/A

All the Citrix XML Services configured for farm Cloud failed to respond to this XML Service transaction.

Log Name: Citrix Delivery Services

Source: Citrix Store Service

Event ID: 28

Level: Warning

User: N/A

Failed to launch the resource 'Cloud.Workspace $S32-61' using the Citrix XML Service at address 'http://citrixcloud1.contoso.com/scripts/wpnbr.dll'. All the Citrix XML Services configured for farm Cloud failed to respond to this XML Service transaction.

com.citrix.wing.SourceUnavailableException, PublicAPI, Version=3.12.0.0, Culture=neutral, PublicKeyToken=null

All the Citrix XML Services configured for farm Cloud failed to respond to this XML Service transaction.

at com.citrix.wing.core.mpssourceimpl.MPSFarmFacade.GetAddress(Context ctxt, String appName, String deviceId, String clientName, Boolean alternate, MPSAddressingType requestedAddressType, String friendlyName, String hostId, String hostIdType, String sessionId, NameValuePair[] cookies, ClientType clientType, String retryKey, LaunchOverride launchOverride, Nullable`1 isPrelaunch, Nullable`1 disableAutoLogoff, Nullable`1 tenantId, String anonymousUserId)

at com.citrix.wing.core.mpssourceimpl.MPSLaunchImpl.GetAddress(Context env, String appName, String deviceId, String clientName, Boolean alternate, MPSAddressingType requestedAddressType, String friendlyName, String hostId, String hostIdType, String sessionId, NameValuePair[] cookies, ClientType clientType, String retryKey, LaunchOverride launchOverride, Nullable`1 isPrelaunch, Nullable`1 disableAutoLogoff, Nullable`1 tenantId, String anonymousUserId)

at com.citrix.wing.core.mpssourceimpl.MPSLaunchImpl.LaunchRemoted(Dictionary`2 parameters, Context env, AppLaunchParams appLaunchParams)

at com.citrix.wing.core.mpssourceimpl.MPSLaunchImpl.Launch(Dictionary`2 parameters, Context env, AppLaunchParams appLaunchParams)

at com.citrix.wing.core.applyaccessprefs.AAPLaunch.Launch(Dictionary`2 parameters, Context env, AppLaunchParams appLaunchParams)

at com.citrix.wing.core.clientproxyprovider.CPPLaunch.Launch(Dictionary`2 parameters, Context env, AppLaunchParams appLaunchParams)

at com.citrix.wing.core.connectionroutingprovider.CRPLaunch.LaunchInternal(Dictionary`2 parameters, Context env, AppLaunchParams appLaunchParams, Boolean useAlternateAddress)

at com.citrix.wing.core.connectionroutingprovider.CRPLaunch.Launch(Dictionary`2 parameters, Context env, AppLaunchParams appLaunchParams)

at com.citrix.wing.core.bandwidthcontrolprovider.BCPLaunch.Launch(Dictionary`2 parameters, Context env, AppLaunchParams appLaunchParams)

at Citrix.DeliveryServices.ResourcesCommon.Wing.WingAdaptors.OverrideIcaFileLaunch.Launch(Dictionary`2 launchParams, Context env, AppLaunchParams appLaunchParams)

at Citrix.DeliveryServices.ResourcesCommon.Wing.WingAdaptors.LaunchUtilities.IcaLaunch(IRequestWrapper request, Resource resource, LaunchSettings launchSettings, String retryKey)

com.citrix.wing.core.xmlclient.types.WireException, Private, Version=3.12.0.0, Culture=neutral, PublicKeyToken=null

HttpErrorPacket(500,Internal Server Error)

at com.citrix.wing.core.xmlclient.transactions.TransactionTransport.handleHttpErrorPacket(Int32 httpErrorStatus, String httpReasonPhrase)

at com.citrix.wing.core.xmlclient.transactions.CtxTransactionTransport.receiveTransportHeaders()

at com.citrix.wing.core.xmlclient.transactions.CtxTransactionTransport.receiveResponsePacketImpl(XmlMarshall marshaller)

at com.citrix.wing.core.xmlclient.transactions.ParsedTransaction.sendAndReceiveXmlMessage(XmlMessage request, AccessToken accessToken)

at com.citrix.wing.core.xmlclient.transactions.nfuse.NFuseProtocolTransaction.SendAndReceiveSingleNFuseMessage[TRequest,TResponse](TRequest request, AccessToken accessToken)

at com.citrix.wing.core.xmlclient.transactions.nfuse.AddressTransaction.TransactImpl()

at com.citrix.wing.core.xmlclient.transactions.ParsedTransaction.Transact()

at com.citrix.wing.core.mpssourceimpl.MPSFarmFacade.GetAddress(Context ctxt, String appName, String deviceId, String clientName, Boolean alternate, MPSAddressingType requestedAddressType, String friendlyName, String hostId, String hostIdType, String sessionId, NameValuePair[] cookies, ClientType clientType, String retryKey, LaunchOverride launchOverride, Nullable`1 isPrelaunch, Nullable`1 disableAutoLogoff, Nullable`1 tenantId, String anonymousUserId)

Errors on VDAs (Virtual Desktop Agents / VDIs)

Logging directly onto the VDAs will reveal many warnings and errors related to the Citrix Cloud Connector connectivity:

Log Name: Application
Source: Citrix Desktop Service

Event ID: 1014

Level: Warning

The Citrix Desktop Service lost contact with the Citrix Desktop Delivery Controller Service on server ‘citrixcloud1.contoso.com’. The service will now attempt to register again.

Citrix Cloud Connectors

Review the Cloud Connector connectivity via the Citrix portal will show the cloud connectors with warnings at times and green at other times.

Running a Run Health Check will take more than expected and while it completes, the status of the connector may or may not indicate the last checked date.

Citrix Cloud Backend Logs

Opening a ticket with Citrix Support and having the engineer review the backend Citrix Cloud connections will reveal an abnormal amount of disconnects. The following was the report we received:

13k events related to Connected/Disconnected/ConnectingFailed in the past 24 hours

038041d1-acac-4903-b88a-817b312f2a1c = citrixcloud2.contoso.com 2270 events disconnected

0812a411-754e-4b03-a6cf-382764a63a6 = citrixcloud3.contoso.com 1782 events disconnected

5ebc62a9-a015-492a-81dd-ceb649fda8f3 citrixcloud1.contoso.com 2508 for disconnected

Solution

This issue took quite a bit of time to resolve as the FortiOS upgrade to 6.2.3 was completed 2 weeks prior to the virtual desktop connectivity issues to begin so it was the last place I thought would be the problem. After eliminating every single possibility that there was something wrong with the Citrix environment, I asked the network engineer to open up a ticket with Fortinet to see if they can perform a more in depth tracing for the packets sent and received between the firewall and the Citrix Cloud. To our surprise, the Fortinet engineer who finally gave us a call back immediately indicated that we may be experiencing a bug in the FortiOS 6.2.3, which could cause such an issue. The following are the messages we received from the support engineer:

I informed you that, as you have SSO in your config, you could be very well hitting the known issue for internal servers due session being deleted. We will need to run the flow trace at time of disconnect, so that we can confirm the behavior.

We got on a call with the engineer and was able to determine that it was indeed a bug in this version of the FortiOS. The recommended remediation was to upgrade to either a special build of 6.2.3 that addressed this issue or upgrade to 6.2.4. We ended up upgrading to the 6.2.3 build8283 (GA) which resolved our issue.

For those who are interested, the following is the case summary the engineer provided:

1) We discussed the citrix applications were hanging for a prolong period.

2) FGT is currently running the firmware version 6.2.3 and the Citrix server 20.41.61.15 is accessed on the port 443

3) We checked the session list for one of the machines reporting the issue 192.168.5.71 session info: proto=6 proto_state=01 duration=269 expire=268 timeout=300 flags=00000000 sockflag=00000000 sockport=0 av_idx=0 use=5 origin-shaper= reply-shaper=high-priority prio=2 guarantee 0Bps max 134217728Bps traffic 5525Bps drops 0B per_ip_shaper= class_id=0 shaping_policy_id=6 ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/255 user=MROGERS auth_server=BCAUTH state=log may_dirty npu rs f00 acct-ext statistic(bytes/packets/allow_err): org=30896/83/1 reply=35645/59/1 tuples=2 tx speed(Bps/kbps): 114/0 rx speed(Bps/kbps): 132/1 orgin->sink: org pre->post, reply pre->post dev=11->25/25->11 gwy=198.182.170.1/192.168.5.71 hook=post dir=org act=snat 192.168.5.71:58467->20.41.61.15:443(198.182.170.253:58467) hook=pre dir=reply act=dnat 20.41.61.15:443->198.182.170.253:58467(192.168.5.71:58467) pos/(before,after) 0/(0,0), 0/(0,0) src_mac=00:50:56:b0:c1:53 misc=0 policy_id=213 auth_info=0 chk_client_info=0 vd=0 serial=0a35b6a8 tos=ff/ff app_list=0 app=0 url_cat=0 rpdb_link_id = ff000001 ngfwid=n/a dd_type=0 dd_mode=0 npu_state=0x000c00 npu info: flag=0x81/0x81, offload=8/8, ips_offload=0/0, epid=154/140, ipid=140/154, vlan=0x0000/0x0000 vlifid=140/154, vtag_in=0x0000/0x0000 in_npu=1/1, out_npu=1/1, fwd_en=0/0, qid=7/0

4) In the diagnose firewall auth list we could see the source 192.168.1.57 BC-CC-600D-FW01 # diagnose firewall auth list 192.168.5.71, MROGERS type: fsso, id: 0, duration: 559, idled: 0 server: BCAUTH packets: in 2254 out 2034, bytes: in 933560 out 856864 group_id: 4 33554905 33554989 33555163 33555200 33555204 33555203 33555198 33554433 group_name: ALL_BC_AD_USERS CN=OPERATIONS,OU=DISTRIBUTION GROUPS,OU=GROUPS,DC=CONTOSO,DC=COM CN=SECURITY DEPT,OU=SECURITY,OU=OFFICEADMIN,DC=CONTOSO,DC=COM CN=WIRELESSACCESS,OU=SECURITY GROUPS,OU=GROUPS,DC=CONTOSO,DC=COM CN=TESTALLEMPLOYEES,OU=DISTRIBUTION GROUPS,OU=GROUPS,DC=CONTOSO,DC=COM CN=ALL EMPLOYEES,OU=DISTRIBUTION GROUPS,OU=GROUPS,DC=CONTOSO,DC=COM CN=ALLEMPLOYEES,OU=DISTRIBUTION GROUPS,OU=GROUPS,DC=CONTOSO,DC=COM CN=ALLSUPPORTSTAFF,OU=DISTRIBUTION GROUPS,OU=GROUPS,DC=CONTOSO,DC=COM CN=Domain Users,CN=Users,DC=CONTOSO,DC=COM

5) Further in the debug flow we could see the msg="no session matched" 2020-06-06 18:49:56 id=20085 trace_id=55 func=print_pkt_detail line=5501 msg="vd-root:0 received a packet(proto=6, 192.168.5.71:57775->20.41.61.15:443) from port12. flag [.], seq 1161501577, ack 1787291322, win 255" 2020-06-06 18:49:56 id=20085 trace_id=55 func=vf_ip_route_input_common line=2581 msg="Match policy routing id=2133000193: to 20.41.61.15 via ifindex-25" 2020-06-06 18:49:56 id=20085 trace_id=55 func=vf_ip_route_input_common line=2596 msg="find a route: flag=04000000 gw-198.182.170.1 via port18" 2020-06-06 18:49:56 id=20085 trace_id=55 func=fw_forward_dirty_handler line=385 msg="no session matched"

6) As discussed, we have a know issue of RDP and other applications freezing due to no session match error Bug Id ==> 0605950

7) It seems that when the authed session is changed it clears the non-auth session for the same Ip.

8) The issue is resolved in the newer firmware version 6.2.4. 9) You did not want to upgrade to 6.2.4 so we do have a special build 8283 that resolves this issue. Please upgraded the firmware to this attached build and let us know.