WNetUseConnection give 2202 error code in windows server 2019 but not in windows server 2022

Question

Q1) WNetUseConnection give 2202 error code in windows server 2019 but same code succeded in windows server 2022 why is that ?
Q2) is there any restriction windows server 2019 regarding smb sharefolder ?
Q3) If there is any restriction then what is that and how can i fix so that it will work ?

sample code for understanding :
remoteUncName : \192.168.91.10
username : localusername

password : localuserpassword

            NETRESOURCE netResource = new NETRESOURCE

            {

                DwType = "0x00000001",

                LpRemoteName = remoteUncName ,

            };  

WNetUseConnection(IntPtr.Zero, netResource, password, username, 0, null, null, null);

Answer 1

Hi @Venkatesh Naik ,

Thanks for reaching out.

You’re running into a combination of OS behavior differences and a few subtle but important implementation details.

First, the UNC path itself matters. In the failing example, the path is specified as \\192.168.91.10 without a share name. Windows Server 2019 will reject this outright. You must always provide a full UNC path, including the share, for example:

\\192.168.91.10\ShareName

Server 2022 may seem more tolerant in some scenarios, but in practice, a UNC without a share (\\server) usually won’t succeed for connection calls. Always use the full \\server\share path.

Second, there are a couple of API usage details to correct:

• In the NETRESOURCE structure, ensure:
  • lpRemoteName = full UNC, e.g., \\192.168.91.10\ShareName
  • dwType = numeric constant RESOURCETYPE_DISK (DWORD), not a string
• For more explicit and predictable credential handling, consider WNetAddConnection2 or WNetAddConnection3 instead of WNetUseConnection.

For credentials, be explicit. On Server 2019 in particular:

• Use SERVERNAME\localusername or DOMAIN\username
• Prefer the server’s NetBIOS name over the IP address in the username when possible

Permissions:

• Verify that the account has both share permissions and NTFS permissions on the target folder. Both are required - having only one may still cause the connection to fail.

From an environment perspective, double-check the basics:

• Firewall: ensure File and Printer Sharing (SMB-In) on port 445 is enabled
• Services: confirm the Server service is running on the host and Workstation is running on the client

On the SMB and authentication side, Server 2019 enforces stricter defaults:

• NTLMv2 is required; guest or anonymous access is typically blocked
• If security baselines are applied, SMB signing and/or encryption may be required, and the client must negotiate them
• Do not enable SMB1

Cached sessions can also cause repeated failures: if there is an existing cached connection to the same \\server\share with different credentials, clear it first (net use \\server\share /delete or WNetCancelConnection2) before retrying with the correct credentials.

For troubleshooting, use:

• Validate access outside of code via the command line:

  
    net use \\192.168.91.10\ShareName /user:SERVERNAME\localusername password
  
  

• Retrieve precise error messages using WNetGetLastError (preferred for WNet* APIs) or FormatMessage. This will help pinpoint whether the failure is due to username format, permissions, policy, or path issues.

Hope this helps! If my answer was helpful - kindly follow the instructions here so others with the same problem can benefit as well.

Answer 2

Hello jack

thank you for the reply

In the `NETRESOURCE` structure, ensure:

• • lpRemoteName = full UNC, e.g., \\192.168.91.10\ShareName
  • dwType = numeric constant RESOURCETYPE_DISK (DWORD), not a string
• For more explicit and predictable credential handling, consider WNetAddConnection2 or WNetAddConnection3 instead of WNetUseConnection.

=> we have used UNC path as this \\192.168.91.10\ and RESOURCETYPE_DISK (DWORD) is not a string in our application.
when it comes to WNetAddConnection2 and WNetAddConnection3 we can't use this yet
as we need confirmation of WNetUseConnection does not works in windows server 2019 and works in windows server 2022

For credentials, be explicit. On Server 2019 in particular:

• Use SERVERNAME\localusername or DOMAIN\username
• Prefer the server’s NetBIOS name over the IP address in the username when possible

=> in windows server 2019 if i use domain user(domainname\username) instead if local user the smb access is succeded
but when i use local user (username) it does not work
but for local user in windows server 2022 it works without SERVERNAME\localusername

Permissions:
=> folder has Share and NTFS permission.

**environmen
=> firewall setting are also ok and same in 2022 and 2019

below command succedes in windows server 2019
=> net use \192.168.91.10\ShareName /user:SERVERNAME\localusername password

and

net use \192.168.91.10 /user:localusername password

**On the SMB and authentication side, Server 2019 enforces stricter defaults:
=> NTLMv2 is on ****

Answer 3

The error code 2202 indicates that the user name or group name parameter is invalid. This can occur due to several reasons, including specifying an incorrect user name or group name when calling the WNetUseConnection function. The difference in behavior between Windows Server 2019 and Windows Server 2022 could be attributed to changes in how user authentication and network connections are handled in these two versions of the operating system.

As for restrictions regarding SMB share folders in Windows Server 2019, there may be specific configurations or settings that differ from Windows Server 2022. These could include permissions, network policies, or SMB protocol versions that affect connectivity and authentication.

To resolve the issue and ensure that the connection works in Windows Server 2019, consider the following steps:

1. Verify User Credentials: Ensure that the username and password you are using are correct and have the necessary permissions to access the SMB share.
2. Check Network Configuration: Make sure that the network settings and firewall configurations on Windows Server 2019 allow for SMB traffic.
3. Review SMB Settings: Check if the SMB version enabled on Windows Server 2019 is compatible with the server hosting the share. You may need to enable or configure SMBv1, SMBv2, or SMBv3 based on your environment.
4. Test with Different User Accounts: If possible, try using a different user account that has confirmed access to the share to rule out account-specific issues.

If the problem persists, further investigation into the specific error messages and logs on Windows Server 2019 may be necessary to identify the root cause.

---

References:

• Terminal Server error messages: 2200 to 2299
• Adding a Network Connection