[WINDOWS] An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full

 Trên window khi truy cập 1 số ứng dụng bị lỗi "An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full" . Hoặc mã lỗi 'WSAENOBUFS (10055)'

ngoài ra, 1 số website hoặc dịch vụ khác cũng bị lỗi truy cập

Nguyên nhân : từ server có outbound connect port > 5000, thường có quá nhiều kết nối outbound từ server nên không đủ source port đẻ sử dụng

tham khảo : https://learn.microsoft.com/vi-vn/troubleshoot/windows-client/networking/connect-tcp-greater-than-5000-error-wsaenobufs-10055

 

Xử lý  : Trước tiên kiểm tra netstat -na xem có đang kết nối outbound ra nhiêu không và có thể xử lý nếu xác định 1 đối tượng nào đó gây overload

VD: 

Trường hợp không có outbound connection nhiều thì có thể xử lý chỉnh registry theo link https://learn.microsoft.com/vi-vn/troubleshoot/windows-client/networking/connect-tcp-greater-than-5000-error-wsaenobufs-10055

The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248

The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters

C1 : mở regedit
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
chọn DWORD : LongPathsEnabled set value 1

C2: Mở Policy gpedit.msc
Computer Configuration > Administrative Templates > System > Filesystem
"Enable win32 long paths" --> Enable

IIS/WEB site
system.web/httpRuntime/maxURLLength : mặc định 260
-> set tăng lên

<system.web>
<httpRuntime maxUrlLength="500" />
</system.web>


Trên application manifest cần khai báo thêm longPathAware

<application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
        <ws2:longPathAware>true</ws2:longPathAware>
    </windowsSettings>
</application>

https://docs.microsoft.com/vi-vn/windows/win32/fileio/naming-a-file?redirectedfrom=MSDN#maximum-path-length-limitation

[MDaemon]Đồng bộ User từ Active Directory qua Email Server Mdaemon

Trên máy chủ Mdeamon chúng ta làm những thao tác sau:

1. Accounts -> account settings -> active directory-> monitoring: 
– tick check box: monitor active directory for user
– tick check box: use active directory domain names (nhập domain : tencongty)
2. Accounts -> account settings -> active directory-> options : 
– base entry DN: LDAP://server ip/OU=tenou,DC=tencongty,DC=com.
– bind DN: administrator (user administrator cua ad)
– password: pass admin ad
3. Accounts -> account settings -> active directory-> monitoring: click perform full AD scan now.

Khi bạn kết thúc, click perform full AD scan now thì trong tab system sẽ hiển thị quá trình nhận user của MDaemon từ AD.
Khi đã nhận xong user ta có thể kiểm tra trong phần Accounts-> accounts manager.
Thời gian đồng bộ giữa server MDaemon và AD được thiết lập trong phần : Accounts setting ->Active directory -> Query Active directory for new data every.

Chúc bạn thành công

[WINDOWS] - Window 2012 - 2016 stuck at RDP - Please wait for the local session manager

I would like to report a huge bug in Windows Server 2012 and 2016. For 2012 I need to try multiple times to log in to system using RDP but for upgrading 2012 to 2016 I can't log in at all. Everything is described here:

https://social.technet.microsoft.com/Forums/systemcenter/en-US/b45761b1-3949-4c9c-9e88-7d70cef6990f/long-delay-to-log-in-please-wait-for-the-local-session-manager?forum=ws2016

Basically during RDP logging in process lsass.exe process is parsing ALL local users which takes too much time and incoming RDP session is being disconnected. As far as I can see in Windows Event log about 800-900 local users are being parsed before disconnection occurs.

During logging in process lsass.exe is using large amount of CPU but this is probably realted to checking registry:

https://social.msdn.microsoft.com/Forums/getfile/1079226

As you can see in ProcessManager from time when RDP connection was made 21% of ALL Windows events logged in Process Manager was from lsass.exe process.

There is a easy way to replicate this issue:

I can replicate this bug
1) RDP to a newly created Windows Server
2) create a batch file with the following content:
:start
net user /add user%random%_%random% /random
timeout 1
goto start
open command prompt and execute the batch file.
Wait 20 minutes
try to RDP or connect via console. It won't work.

(and as far as I know it was replicated on MS side but for now nothing is being done or decided what to do with this problem).

Solution for this issue can be just extending RDP timeout which will work just fine because lsass.exe is using more CPU only during local users traversing and after logging in it just drops.

Any ideas/suggestions? Except "just use AD" ok? This specific scenario is on system which holds shared hosting accounts and local users are being used just for keeping website separated from each other and I really don't need AD for this one.

Solution from MS:

We found that each iteration (happening in LogonUI ) makes a call out to LSASS.exe which performs the UserLookup and returns the SID information. This is what it is taking time.

This kind of extensive lookup happens because of new functions introduced from Win2012 onwards.

To turn this lookup off, please add the following registry key ( both the locations ), reboot the machine and then test and let me know the results.

Location 1: HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\System
Location 2: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Key: DontDisplayLastUserName
Type: DWORD
Value: 1

refer : https://windowsserver.uservoice.com/forums/295047-general-feedback/suggestions/19532398-unable-to-log-in-using-rdp-on-windows-server-2012