You may have to wait for a long time to populate the information on shared folder sessions in Computer Management console

This article provides a solution to an issue where information on shared folder sessions is populated slow in Computer Management console.

Original product version: В Windows Server 2012 R2
Original KB number: В 2454039

Symptoms

When trying to view the information about client sessions by clicking Shared Folders > Sessions in the Computer Management console, it may take a long time to populate the information, and the console may stop responding or appear to hang.

Cause

Computer Management will try to resolve the client IP address to user-friendly NetBIOS name. In and IPv6 and IPv4 hybrid environment, and clients use NetBIOS to access share folders, if the NetBIOS name cannot be resolved, it shows the IPv6 address immediately. However, if clients are using ipv4 to access share folder, the failure of resolving to the NetBIOS name causes the Computer Management console to hang.

Resolution

Disable NetBIOS over TCP/IP:

1. Run ncpa.cpl.
2. Right-click the NIC.
3. Select properties.
4. Click TCPIPV4.
5. Click advanced.
6. Click WINS.
7. Choose Disable Netbios over TCPIP.

Configure reverse lookup zone in DNS server. It is useful to computers that are added in domain.

Creating a Pseudoconsole session

The Windows Pseudoconsole, sometimes also referred to as pseudo console, ConPTY, or the Windows PTY, is a mechanism designed for creating an external host for character-mode subsystem activities that replace the user interactivity portion of the default console host window.

Hosting a pseudoconsole session is a bit different than a traditional console session. Traditional console sessions automatically start when the operating system recognizes that a character-mode application is about to run. In contrast, a pseudoconsole session and the communication channels need to be created by the hosting application prior to creating the process with the child character-mode application to be hosted. The child process will still be created using the CreateProcess function, but with some additional information that will direct the operating system to establish the appropriate environment.

You can find additional background information about this system on the initial announcement blog post.

Complete examples of using the Pseudoconsole are available on our GitHub repository microsoft/terminal in the samples directory.

Preparing the communication channels

The first step is to create a pair of synchronous communication channels that will be provided during creation of the pseudoconsole session for bidirectional communication with the hosted application. These channels are processed by the pseudoconsole system using ReadFile and WriteFile with synchronous I/O. File or I/O device handles like a file stream or pipe are acceptable as long as an OVERLAPPED structure is not required for asynchronous communication.

To prevent race conditions and deadlocks, we highly recommend that each of the communication channels is serviced on a separate thread that maintains its own client buffer state and messaging queue inside your application. Servicing all of the pseudoconsole activities on the same thread may result in a deadlock where one of the communications buffers is filled and waiting for your action while you attempt to dispatch a blocking request on another channel.

Creating the Pseudoconsole

With the communications channels that have been established, identify the «read» end of the input channel and the «write» end of the output channel. This pair of handles is provided on calling CreatePseudoConsole to create the object.

On creation, a size representing the X and Y dimensions (in count of characters) is required. These are the dimensions that will apply to the display surface for the final (terminal) presentation window. The values are used to create an in-memory buffer inside the pseudoconsole system.

The buffer size provide answers to client character-mode applications that probe for information using the client-side console functions like GetConsoleScreenBufferInfoEx and dictates the layout and positioning of text when clients use functions like WriteConsoleOutput.

Finally, a flags field is provided on creation of a pseudoconsole to perform special functionality. By default, set this to 0 to have no special functionality.

At this time, only one special flag is available to request the inheritence of the cursor position from a console session already attached to the caller of the pseudoconsole API. This is intended for use in more advanced scenarios where a hosting application that is preparing a pseudoconsole session is itself also a client character-mode application of a another console environment.

A sample snippet is provided below utilizing CreatePipe to establish a pair of communication channels and create the pseudoconsole.

This snippet is incomplete and used for demonstration of this specific call only. You will need to manage the lifetime of the HANDLEs appropriately. Failure to manage the lifetime of HANDLEs correctly can result in deadlock scenarios, especially with synchronous I/O calls.

Upon completion of the CreateProcess call to create the client character-mode application attached to the pseudoconsole, the handles given during creation should be freed from this process. This will decrease the reference count on the underlying device object and allow I/O operations to properly detect a broken channel when the pseudoconsole session closes its copy of the handles.

Preparing for Creation of the Child Process

The next phase is to prepare the STARTUPINFOEX structure that will convey the pseudoconsole information while starting the child process.

This structure contains the ability to provide complex startup information including attributes for process and thread creation.

Use InitializeProcThreadAttributeList in a double-call fashion to first calculate the number of bytes required to hold the list, allocate the memory requested, then call again providing the opaque memory pointer to have it set up as the attribute list.

Next, call UpdateProcThreadAttribute passing the initialized attribute list with the flag PROC_THREAD_ATTRIBUTE_PSEUDOCONSOLE, the pseudoconsole handle, and the size of the pseudoconsole handle.

Creating the Hosted Process

Next, call CreateProcess passing the STARTUPINFOEX structure along with the path to the executable and any additional configuration information if applicable. It is important to set the EXTENDED_STARTUPINFO_PRESENT flag when calling to alert the system that the pseudoconsole reference is contained in the extended information.

Closing the pseudoconsole session while the hosted process is still starting up and connecting can result in an error dialog being shown by the client application. The same error dialog is shown if the hosted process is given an invalid pseudoconsole handle for startup. To the hosted process initialization code, the two circumstances are identical. The pop-up dialog from the hosted client application on failure will read 0xc0000142 with a localized message detailing failure to initialize.

Communicating with the Pseudoconsole Session

Once the process is created successfully, the hosting application can use the write end of the input pipe to send user interaction information into the pseudoconsole and the read end of the output pipe to receive graphical presentation information from the pseudo console.

It is completely up to the hosting application to decide how to handle further activity. The hosting application could launch a window in another thread to collect user interaction input and serialize it into the write end of the input pipe for the pseudoconsole and the hosted character-mode application. Another thread could be launched to drain the read end of the output pipe for the pseudoconsole, decode the text and virtual terminal sequence information, and present that to the screen.

Threads could also be used to relay the information from the pseudoconsole channels out to a different channel or device including a network to remote information to another process or machine and avoiding any local transcoding of the information.

Resizing the Pseudoconsole

Throughout the course of runtime, there may be a circumstance by which the size of the buffer needs to be changed due to a user interaction or a request received out of band from another display/interaction device.

This can be done with the ResizePseudoConsole function specifying both the height and width of the buffer in a count of characters.

Ending the Pseudoconsole Session

To end the session, call the ClosePseudoConsole function with the handle from the original pseudoconsole creation. Any attached client character-mode applications, such as the one from the CreateProcess call, will be terminated when the session is closed. If the original child was a shell-type application that creates other processes, any related attached processes in the tree will also be terminated.

Closing the session has several side effects which can result in a deadlock condition if the pseudoconsole is used in a single-threaded synchronous fashion. The act of closing the pseudoconsole session may emit a final frame update to hOutput which should be drained from the communications channel buffer. Additionally, if PSEUDOCONSOLE_INHERIT_CURSOR was selected while creating the pseudoconsole, attempting to close the pseudoconsole without responding to the cursor inheritence query message (received on hOutput and replied to via hInput ) may result in another deadlock condition. It is recommended that communications channels for the pseudoconsole are serviced on individual threads and remain drained and processed until broken of their own accord by the client application exiting or by the completion of teardown activities in calling the ClosePseudoConsole function.

Подключаемся к консоли терминального сервера через удаленный рабочий стол (RDP)

Подключаемся к консоли терминального сервера через удаленный рабочий стол (RDP)

Бывает такие случаи, когда при использовании RDP (Remote Desktop Protocol — протокол удалённого рабочего стола), не видно программ, которые установленные в системном трее, или ошибки и уведомления просто не отображаются. Для того, чтобы решить данную проблему, к терминальному северу можно подключиться в консольном режиме через тот же RDP.

Удаленный рабочий стол (Remote Desktop Protocol) или RDP — это технология дистанционного подключения к компьютеру (серверу), для непосредственного управлению им через локальную сеть или интернет. Я уже рассказывал о данной технологии в видеоуроке «Подключение к компьютеру через удаленный рабочий стол».

Использование, каких-либо программ удаленного администрирования для подключения к рабочему столу напрямую не всегда удобно, например, при нестабильной связи или ограничении времени сеанса. Так вот в данной статье мы расскажем, о нехитрой вещи, которую некоторые коллеги возможно не знали.

При использовании клиента удаленного рабочего стола (RDP) Windows, в качестве средства подключения к компьютеру с Windows Server 2003/2008/2012 с запущенной службой сервера терминалов, у вас есть возможность подключения на консоль сервера. Используя эту опцию, вы можете войти на сервер, так, как если бы вы сидели прямо перед ним, а не создавать новые сессии через сетевое подключение. Дело в том, что при удаленной установке некоторых программ, могут возникнуть проблемы, которые не позволят вам сделать это из терминальной сессии, поэтому вам понадобиться войти на сервер через консоль.

Включение удаленного доступа на своем компьютере.

Для того, чтобы настроить удаленный доступ на целевом компьютере, владелец или администратор должен выполнить следующие действия (Мой компьютер \ Свойства \ Настройка удаленного доступа \ Удаленный доступ \ Разрешить подключение от компьютеров с любой версией удаленного рабочего стола).

Если хотите пускать в свой компьютер только определённых пользователей или группы пользователей вашей сети, то необходимо поставить галочку «Разрешить подключение с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети (рекомендуется)».

Как же подключиться к удаленному рабочему столу?

Это конечно же стандартными средствами Windows (Пуск \ Все программы \ Стандартные \ Подключение к удалённому рабочему столу)

Или через команду Выполнить (Win+R) и вводим команду mstsc. Это более быстрый способ и его используют в основном админы и разработчики программ, т.к. часто приходится подключаться к удаленным рабочим столам серверов.

Как же подключиться к консоли удаленного рабочего стола?

Для этого в появившемся окне вбиваем команду:

— Windows Server 2003 и Windows XP: mstsc /console

— Windows Server 2008/2012 и Windows 7/8/8.1: mstsc /admin

Вводим имя терминального севера или компьютера.

И вводим учетные данные пользователя имеющего права для удаленного подключения.

Так как RDP по умолчанию создаёт виртуальную консоль, то подключение происходит не к самой сессии, а непосредственно к консоли (основная консоль-мышь/клавиатура).

Какая разница между простым подключением к удаленному рабочему столу и подключением к консоли?

— Подключение через консоль — доступно только администраторам и фактически приравнивается к обыкновенному входу в систему. Тогда как простое подключение по rdp — это терминальная сессия, соответственно то программное обеспечение, которое сопротивляется запуску под терминальной сессией, под консолью может вполне успешно работать.

— В первом случае создается новая сессия (mstsc), параллельная с существующей. Во втором случае подключение осуществляется к своему рабочему столу (в рамках лицензий на терминал).