To keep OBS running after you disconnect from an Azure VM, close or disconnect the Remote Desktop (RDP) client while leaving your Windows account signed in. Keep the VM running, then reconnect to the same session to check OBS.
This preserves the OBS process only when the Windows session and VM remain available. It does not guarantee that YouTube continues receiving a healthy stream: the broadcast can fail even while OBS stays open.
Disconnect RDP; do not sign out
When you close the RDP window, you are ending the connection between your local computer and the remote desktop. In the ordinary Windows VM case, that leaves the remote Windows session running in a disconnected state, so its existing applications can continue executing. The exact experience can vary with the way you connect and with settings applied to the host.
Use the RDP client’s close or disconnect action. Do not select Sign out, Log off, or a similarly named command from Windows or the remote desktop menu. Those actions end the Windows session rather than merely hiding the desktop from your local computer. If OBS is running inside that session, signing out is not a way to preserve its current process.
Before you close the client, make sure the broadcast is already underway. In OBS, check that the expected scene is selected and that the stream is active; confirm the corresponding live state in YouTube Studio if you can. A disconnected desktop is harder to diagnose, so it is worth checking the basics while you still have control.
This approach is for someone who wants the current OBS session to continue while they leave the remote desktop. It is not a substitute for a service designed to run independently of an interactive Windows session, nor does it prevent VM power actions, session policies, application crashes, or network trouble.
What an RDP disconnect leaves behind
A useful way to think about this is to separate three things: the local RDP client, the Windows session on the VM, and the stream connection from OBS to YouTube. Closing the client changes the first. If the session remains signed in and the VM remains on, the other two may continue, but they are not the same thing and one does not prove the health of another.
Microsoft documents that a remote session may become disconnected and be available for reconnection. Session locking behaviour depends on the connection and authentication setup, and administrators can set policies that change it. For Azure Virtual Desktop, Microsoft describes how session lock behaviour can be configured; see its session lock guidance. A conventional Azure VM accessed directly over RDP is not automatically the same arrangement as Azure Virtual Desktop.
A lock screen is not the same as signing out. Your session may lock when you disconnect, depending on configuration, while remaining present for you to reconnect to. That distinction matters for an interactive app such as OBS. If you reconnect and see a lock screen, unlock the account and inspect the existing desktop rather than assuming the process has ended.
Also consider what OBS depends on. A scene built from files on the VM is different from one using a display, audio device, or other resource supplied by the remote session. If a source disappears or changes when you disconnect, the OBS process may still be alive while the scene behaves differently. The source setup and connection method matter; do not assume every Azure VM has the same devices or session behaviour.
Disconnect, sign out, restart, and stop are different
These actions have different consequences. Use the table to identify what happened before troubleshooting. In particular, closing a client window is not a power-management command, while a VM shutdown or restart does interrupt running processes.
| Action | What changes | What to expect for the current OBS process |
|---|---|---|
| Close or disconnect the RDP client | The local remote-desktop connection ends | The Windows session may remain disconnected and available to reconnect; check the host’s configuration |
| Sign out of Windows | The interactive Windows session ends | Do not expect the existing OBS process in that session to be preserved |
| Restart the VM | Windows shuts down and starts again | The current OBS process stops during the restart; OBS would need to be launched again |
| Stop or deallocate the VM | The VM is powered off or made unavailable for compute | OBS cannot continue running while the VM is stopped |
If you are unsure which action you took, do not infer the answer from the RDP window disappearing. Try reconnecting to the VM. If it is running and you return to the same signed-in session, inspect OBS. If the VM is stopped, start it only if you are authorised to do so and understand the effect on any other workloads. Starting a VM again does not restore the old OBS process; it starts a new Windows run.
A VM may also be stopped by an administrator, an automation schedule, or another power-management action. Closing RDP does not prevent those actions. If a channel depends on OBS being live overnight, confirm that the VM is expected to remain powered on and that no planned maintenance or schedule will shut it down. For an organisation-managed VM, ask its administrator rather than changing policy or power settings yourself.
Leave the Windows account signed in
The practical rule is simple: leave the account signed in, even if the session is locked, and leave the VM running. Do not use the Windows Start menu’s sign-out command, a remote-session menu’s log-off command, or a shutdown option as a way to leave the stream unattended. Those are separate from disconnecting the RDP client.
If several people use the VM, make sure everyone understands which account owns the OBS session and who is allowed to sign it out. A colleague may reasonably assume that signing out is good housekeeping, but it can end the session that contains OBS. Write down the intended action in a short handover: disconnect the client; do not sign out or stop the VM; reconnect to verify the channel.
Whether a session locks immediately can depend on authentication mode and policy. Microsoft’s documentation for connecting to a Remote PC with Microsoft Entra single sign-on explains that this connection path has its own behaviour; the single sign-on documentation is relevant if that is how you connect. Azure Virtual Desktop and ordinary VM RDP can differ, and organisation policies may override defaults.
If the session logs off or disconnects in a way you did not expect, note the time and how you connected, then ask the host administrator to review session time limits and lock policies. Do not change Group Policy or Intune settings just to keep OBS open unless you are responsible for that host and have considered the security implications. Microsoft notes that policy changes to Azure Virtual Desktop session behaviour may require a session-host restart, which itself stops running processes.
Reconnect to the same session and verify OBS
Treat a reconnect as a check, not as proof that the stream has been healthy throughout. Use the same VM and Windows account, connect again, and see whether you have returned to the existing desktop. A new sign-in or a fresh desktop may indicate that the previous session ended or that the connection method created a different session.
Use this sequence when you return:
- Confirm that you connected to the intended VM and account.
- Check whether the existing Windows desktop is open or locked, and unlock it if needed.
- Look for OBS in the taskbar or switch between open applications. If it is open, check the selected scene, preview, stream status, and any visible warnings.
- Check YouTube Studio or the channel’s live view separately to confirm whether YouTube is receiving the broadcast.
- If the live feed is absent or stale, note whether OBS is still running before you restart anything. That observation helps separate a session problem from a stream connection problem.
A reconnect feature in an RDP client concerns the remote desktop connection, not YouTube ingest. Microsoft’s supported RDP properties describe connection properties, including automatic reconnection settings. Those can help the client retry after a network drop; they do not make OBS more persistent, keep the VM powered on, or confirm that the stream reached YouTube.
If you return to a lock screen, unlock it and inspect OBS. If you reach a new desktop and OBS is absent, do not immediately conclude that the VM failed: first establish whether the account signed out, the VM restarted, or you entered another session. Check available VM activity or ask an administrator if you cannot tell. The diagnostic detail determines the next step.
If OBS is open but the stream has stopped
OBS running and a healthy YouTube broadcast are separate states. OBS can remain open after the RDP client disconnects while its connection to YouTube fails. In that case, the right investigation is the stream path, not whether the remote desktop window stayed open.
Check OBS’s status and logs, then look for a specific error before changing settings. OBS identifies an unstable or insufficient connection to the streaming ingest server, bitrate limits, VPN interference, and security software as possible causes. Its stream connection troubleshooting guide provides steps to investigate those symptoms. A firewall, route, or VPN can affect traffic independently of whether RDP remains connected.
If you are streaming from a regional provider or virtual machine and suspect a route or firewall issue, compare the OBS error and timing with the network path rather than making random bitrate changes. The checks in this guide to YouTube stream disconnects on a BSNL VPS are relevant when that specific network context applies. They are not a universal diagnosis for every Azure VM.
If OBS itself has closed or crashed, treat that as an application failure. Review the OBS log, note when the failure occurred, and consider whether a source, plugin, or resource issue is involved. The checklist for OBS crashes after several hours covers a separate class of failures. Do not assume that an RDP disconnect caused a crash just because you noticed it after reconnecting.
For a continuing channel, write down what you observed: whether the VM was on, whether the same Windows session returned, whether OBS was open, and whether YouTube showed the stream. This record makes it easier to distinguish a policy or VM event from an OBS-to-ingest problem. If the broadcast matters overnight, a planned check before leaving and another check after reconnecting are more useful than assuming that a disconnected client means everything stayed healthy.
When the current session is not the right operating model
The disconnect-and-reconnect method depends on a signed-in Windows session remaining available. It is appropriate when you already run OBS interactively on a VM and want to stop watching the desktop without ending that session. It is less suitable if your requirement is to survive Windows sign-out, a VM restart, deallocation, or a network failure without intervention; none of those outcomes is delivered by closing RDP.
OBS supports launch parameters such as --startstreaming, which can start a stream when OBS launches, and --minimize-to-tray, which can launch it minimised. OBS documents these in its launch parameters reference. They can help with a deliberate launch routine, but they do not preserve a signed-out session or prevent a VM from stopping. Nor do they guarantee that a broadcast remains connected after a network problem.
If you configure a restart or launch routine, test it while you can observe both OBS and YouTube. Confirm that the correct profile and scene load, that the stream starts only when intended, and that any interactive prompts do not block the process. A command-line option is not a replacement for testing the actual VM, account, and stream setup. Also consider whether unattended OBS aligns with your organisation’s access and security policies.
For a channel built around a prerecorded file rather than live desktop sources, a workflow that does not depend on your own interactive OBS session may remove the need to leave a remote desktop logged in. For example, the FFmpeg looping approach for recorded lectures explains a different way to broadcast a prepared video. That is a format and workflow choice, not a fix for an OBS session that has already ended. Choose it only if it fits the content and your operating requirements.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Can I close the RDP window while OBS is streaming?
Usually, closing the RDP client disconnects your view of the desktop without signing out of the Windows account, so the existing OBS process may continue on a running VM. The exact session behaviour depends on the connection type and host policy. Check by reconnecting rather than treating the closed window as proof that YouTube stayed live.
Should I sign out before I disconnect?
No, not if you are relying on the OBS process already running in that interactive session. Choose disconnect or close the RDP client and leave the account signed in. Signing out ends the session; do not expect the current OBS process to survive it.
Will OBS keep streaming if the Azure VM restarts or stops?
No. A restart interrupts the current process, and OBS cannot run while the VM is stopped or deallocated. You may be able to start OBS again afterwards, but that is a new launch and does not establish that the stream was uninterrupted.
What if OBS is still open but YouTube is offline?
Treat that as a stream connection issue rather than an RDP-session issue. Check OBS’s status and logs, the ingest connection, and possible VPN, firewall, security software, or network causes. Use the OBS troubleshooting guide and verify the result in YouTube Studio.