Connect with the Windows Desktop client

You can access Windows Virtual Desktop resources on devices with Windows 10, Windows 10 IoT Enterprise, and Windows 7 using the Windows Desktop client.

This does not support Window 8 or Windows 8.1.

This only supports Azure Resource Manager objects, to support objects without Azure Resource Manager, see Connect with Windows Desktop (classic) client.

This does not support the RemoteApp and Desktop Connections (RADC) client or the Remote Desktop Connection (MSTSC) client.

Install the Windows Desktop client

Download the client based on your Windows version:

During installation to determine access, select either:

• Install just for you
• Install for all users of this machine (requires admin rights)

To launch the client after installation, use the Start menu and search for Remote Desktop.

Subscribe to a Workspace

To subscribe to a Workspace, choose to either:

• Use a work or school account and have the client discover the resources available for you
• Use the specific URL of the resource

To launch the resource once subscribed, go to the Connection Center and double-click the resource.

To launch a resource from the Start menu, you can find the folder with the Workspace name or enter the resource name in the search bar.

Use a user account

1. Select Subscribe from the main page.
2. Sign in with your user account when prompted.

The resources grouped by workspace will appear in the Connection Center.

The Windows client automatically defaults to Windows Virtual Desktop (classic).

However, if the client detects additional Azure Resource Manager resources, it adds them automatically or notifies the user that they’re available.

Use a specific URL

Select Subscribe with URL from the main page.

Enter either the Workspace URL or an email address:

• For Workspace URL, use the URL provided by your admin.

Available Resources	URL
Windows Virtual Desktop (classic)	https://rdweb.wvd.microsoft.com/api/feeddiscovery/webfeeddiscovery.aspx
Windows Virtual Desktop	https://rdweb.wvd.microsoft.com/api/arm/feeddiscovery
Windows Virtual Desktop (US Gov)	https://rdweb.wvd.azure.us/api/arm/feeddiscovery

• For Email, use your email address.

The client will find the URL associated with your email, provided your admin has enabled email discovery.

Select Next.

Sign in with your user account when prompted.

The resources grouped by workspace will appear in the Connection Center.

Next steps

To learn more about how to use the client, check out Get started with the Windows Desktop client.

If you’re an admin interested in learning more about the client’s features, check out Windows Desktop client for admins.

«Allow Service to Interact with Desktop» Greyed

Hi,
I tried to follow the following set of instructions:

To fix this behavior follow these steps:

1. Right-click My Computer and from the drop down menu click Manage.
2. From the Services and Applications menu, click Services.
3. From the right scroll down menu, double-click Task Scheduler.
4. Click the Log On tab, select the Local System Account and Allow Service to Interact with Desktop options, and then click Apply.
5. Click the General tab, click Start.

which can be found in http://support.microsoft.com/kb/223170

but when I reaced the «Allow Service to Interact with Desktop» I’ve encountered a greyed window with the «
Local System Account» checked.

I’m interested in curing my task scheduler and wonder how to reach a working Task Schedule Properties window.

Replies (3) 

Please go here: http://computerstepbystep.com/task_scheduler_service.html
and read especially the Regedit-Information which shows you how to change Startup type of Task Scheduler from Registry Editor.

I hope that’s helpful.

1 person found this reply helpful

Was this reply helpful?

Sorry this didn’t help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

You’re trying to apply a Windows 2000 fix to a Windows 7 machine? What is the exact Task Scheduler problem that you are trying to fix? Are you trying to import tasks from a previous installation to a new Windows 7 machine?

On operating systems prior to Vista services ran in Session 0 alongside user applications and could easily interact with the desktop, this was widely recognized as a rather serious security risk so to mitigate this security risk Vista and later operating systems isolate services in Session 0 and run applications in other sessions, ergo as a rule services can no longer generally interact with the desktop in the old fashioned manner, programmers must now use a different method to have their services interact with users. The Interactive Services Detection (UI0Detect.exe) service can be run as a workaround to allow those who run legacy services to migrate and keep on running these services without have to rewrite them, I’m not sure if enabling the service will resolve your Task Scheduler problem. It should be noted that the Interactive Services Detection service is provided as a «crutch» to allow migration of legacy services and to allow time for rewriting of legacy services, the Interactive Services Detection service is in itself a security risk so by default it is disabled, word out there is that Microsoft intends to do away completely with this crutch in the near future. With that in mind, if you are trying to import tasks from an older machine you should rework the tasks for the new environment they will be working on rather than use a soon to be yanked crutch.

On Vista and newer operating systems the Task Scheduler plays a critical role in the well being of the operating system so this service can no longer be stopped or changed via the GUI Services Management Console. unless you are running the console under guise of the System account. You can run under guise of the System account with the use of the SysInternals’ PsExec utility:

The link is provided for your information, I do not recommend changing the Task Scheduler configuration to allow it to bend to your needs, do so AT YOUR OWN RISKS! Also keep in mind that while running under the System account you will have unfettered power to completely wreck the Windows installation if you are not careful!

Allow Windows service to interact with desktop

How do I enable «Allow service to interact with desktop» programmatically?

In services.msc > Action > Properties > Log On > Allow service to interact with desktop, I can enable my service to interact with the desktop. I want my service to play sound (MP3, WAV, etc.).

3 Answers 3

I’m going to take some liberties in here in trying to interpret your question from keywords. In the future, please spend more time writing your questions so that they make sense to another person who is trying to read and understand them.

There is a checkbox under the Log On tab in the properties window for a Windows service that is called «Allow service to interact with desktop.» If you’re trying to check that box programmatically, you need to specify the SERVICE_INTERACTIVE_PROCESS flag when you create your service using the CreateService API. (See MSDN).

However, note that as of Windows Vista, services are strictly forbidden from interacting directly with a user:

Important: Services cannot directly interact with a user as of Windows Vista. Therefore, the techniques mentioned in the section titled Using an Interactive Service should not be used in new code.

This «feature» is broken, and conventional wisdom dictates that you shouldn’t have been relying on it anyway. Services are not meant to provide a UI or allow any type of direct user interaction. Microsoft has been cautioning that this feature be avoided since the early days of Windows NT because of the possible security risks. Larry Osterman argues why it was always a bad idea. And he is not the only one.

There are some possible workarounds, however, if you absolutely must have this functionality. But I strongly urge you to consider its necessity carefully and explore alternative designs for your service.

How to set “interact with desktop” in windows service installer

I have a windows service which runs under system account and executes some programs from time to time (yeah,yeah, I know that’s a bad practice, but that’s not my decision). I need to set the «interact with desktop» check, to see the gui of that executed programs, after the service is installed. I’ve tried several ways, putting the code below in AfterInstall or OnCommited event handlers of my service installer:

both of these methods «work». They set the check, but after I start the service it launches the exe — and gui isn’t shown! So, if I stop the service, recheck and start it again — bingo! everything starts and is shown. The second way to achieve the result is to reboot — after it the gui is also shown.

So the question is: Is there a correct way to set «interact with desktop» check, so it’ll start working without rechecks and reboots?

OS: Windows XP (haven’t tried Vista and 7 yet. )

3 Answers 3

And finally after searching the internet for a week — I’ve found a great working solution: http://asprosys.blogspot.com/2009/03/allow-service-to-interact-with-desktop.html

Find the desktop to launch into. This may seem facetious but it isn’t as simple as it seems. With Terminal Services and Fast User Switching there can be multiple interactive users logged on to the computer at the same time. If you want the user that is currently sitting at the physical console then you’re in luck, the Terminal Services API call WTSGetActiveConsoleSessionId will get you the session ID you need. If your needs are more complex (i.e. you need to interact with a specific user on a TS server or you need the name of the window station in a non-interactive session) you’ll need to enumerate the Terminal Server sessions with WTSEnumerateSessions and check the session for the information you need with WTSGetSessionInformation.

Now you know what session you need to interact with and you have its ID. This is the key to the whole process, using WTSQueryUserToken and the session ID you can now retrieve the token of the user logged on to the target session. This completely mitigates the security problem of the ‘interact with the desktop’ setting, the launched process will not be running with the LOCAL SYSTEM credentials but with the same credentials as the user that is already logged on to that session! No privilege elevation.

Using CreateProcessAsUser and the token we have retrieved we can launch the process in the normal way and it will run in the target session with the target user’s credentials. There are a couple of caveats, both lpCurrentDirectory and lpEnvironment must point to valid values — the normal default resolution methods for these parameters don’t work for cross-session launching. You can use CreateEnvironmentBlock to create a default environment block for the target user.

There is source code of the working project attached.

Windows interact with desktop

What an arrogant and insulting statement, to say that this feature of XP could not possibly be the ideal choice for a developer ever is insanity. Someone tell Sven here to take the blinders off.

My situation is fairly simple, and I’m attempting to use all MS products here, nothing hokey. I am an SDET for a user experience company. We are contracted to develop user interfaces. It’s what we do. These interfaces need to be tested efficiently and on multiple platforms. I currently use Visual Studio test projects to organize and execute automated tests.

To execute these tests on different machines, I would like to utilize Visual Studio 2008’s Test Controller and Test Agent modules. The test agent runs as a Windows service. The tests operate out-of-process so as not to interfere with the codepath, and use Process.Start() to invoke the application being tested.

Naturally, when executing over a test agent this doesn’t really work in Vista. I guess I could write my own ramshackle controller and agent applications over a week or so, but I’d really rather not.

Ignoring Sven’s depressing ignorance, I know Microsoft has an internal application that acts as a test agent and controller that DOES work properly, in spite of being on Vista and running as a service. So there IS a way to pull this off. Can anyone shed some light on it?

In released code, services interacting with the desktop is dangerous. That’s why people are saying ‘don’t do it’ in so many different ways, so strongly. Session 0 isolation is goodness, and UI from services doesn’t have a place in consumer products. Read about the Shatter Attack for some hint as to why session 0 isolation came about.

As for how to debug a service without UI? Services hanging around in different sessions hasn’t bothered me. I debug services frequently attaching to the process, specifying its PID, something many debuggers can do.

If you want to know how to set up Visual Studio 2008’s Test Controller and Test Agent stuff so that it works, try the Visual Studio forums for a much faster, and much more helpful response.

If you want to write a (sane) service that is capable of launching stuff on a visible desktop, there are good ways and bad ways of getting it done.

You should start by reading articles on RpcImpersonateClient, CreateProcessAsUser on MSDN.
There are a number of threads in these forums touching on ‘createprocessasuser from service’ and so forth, which might help.

Note, though, exposing a method to an RPC client that is effectively ‘launch any application with admin privileges’ is a very scary prospect since you can never trust a client at lower privilege.

«services interacting with the desktop is dangerous» — Justify this, where’s your evidence? We implement a graphical rendering service that has to always be available to other processes, this approach places the difficult code outside the ‘high availablity’ GUI (that cannot go down, ever) and into the body of a service, thus when it faults, it crash dumps then the SCM restarts it immediately allowing the rendering outage to be momentary and the impact to the users minimal as the primary application didn’t fail. With the recent changes to Vista, we now basically have to write our own implementation of the SCM as we’re still proceeding with process separation but can no longer make good use of the SCM.

Services with UI are vulnerable to privilege escalation attacks via the so-called Shatter Attack. You shouldn’t need to re-write the SCM, using IPC to communicate between a standard windows service and a helper application running in the user’s context which actually displays any UI should suffice.

Sven, you are a fool. It is not for you to determine what someone’s application needs are. It’s not great that MS dictates when and how everyone should rewrite their applications. Whether or not it’s a good idea to interact with desktop is subjective, but I’m not sure you’ve read the requirements or seen the interface for the application that oilyneck already has written.

Apparently you don’t face the same kind of time & resource constraints as the rest of us down here on earth.

I need the same functionality to work. I’m having a web script from which i need to run a desktop app. This is only for my personal use, on my private PC, not public, so there are no security risks involved. I’ve kept reading about how to get this to work, but no solution. I’ve checked «Allow service to interact with desktop» on my services «Log on» properties, but it doesn’t make any difference. Not only that i don’t see why the checkbox is there if it doesn’t work, i’m wondering how someone like sven can stop me from deciding what programs to allow or disallow to run on my computer. But still, if this doesn’t work, is there any workaround this issue? Can anyone help about how to launch an external app from my web service?

The take away from all of this is that all of you. and I mean all. that claim to NEED service/desktop interaction are not experienced developers. I don’t care how long you’ve written code — you obviously still have the skill set of a recent college grad.

Aluciffer — if you knew anything (AT ALL) about security you would never make this claim «This is only for my personal use, on my private PC, not public, so there are no security risks involved.» You obviously haven’t reverse engineered malware before or have the breadth of knowledge on the topic.

I’m not here to teach so just take the direction that Microsoft is providing. Take this opportunity to grow your design skills and knowledge about the platform you’re developing on. Develop code that works *with* the OS and not against it; that’s the second half of being a good developer. The first obviously is creating clean maintainable source.

Experience has nothing to do with this issue. Many services must interact with users because it’s the only option that makes sense to the user. Disagree? The print spooler service was written by none other than Microsoft. If you hold firm to the opinion that no service should ever interact with the desktop, then you are calling Microsoft and the printer mfrs that write spooler components «inexperienced». If these developers were more «experienced», would print spooler developers do all user interaction through the event log?

Launch services.msc, and a quick glance will show you numerous other services that must interact with desktops. Windows Update is one example.

Microsoft’s solution to shatter attacks is worse than the original problem. Instead of fixing the «shatter attack» vulnerability head-on, MS decided to pull functionality out of Windows. Microsoft’s response to shatter attacks is equivalent to amputating a foot to fix a broken toe.

The individuals that posted suggestions regarding the use of RPC are a bit closer to reality on the ground than Stratcat’s comment. However, the logistics of this RPC topography are unpleasant. Just one example of the logistical challenges: the RPC solution requires applications to ‘auto-start’ on each desktop when the user logs in. This is easily changed by any user with the proper privileges. In my target market, that’s just about every user. Startup folders, the Run registry key, and the task scheduler are well known to users because they turn a 2 minute bootup into 3 minutes of waiting for things not yet in use!

Fix «shatter» and give us back desktop interaction, please! I don’t care if the process has to run as guest and can’t send messages to other applications.

Sorry, for sounding arrogant. I use another liveID and could not reuse SvenC. Maybe I should have started with «No, you don’t ;-)»

Experience has nothing to do with this issue. Many services must interact with users because it’s the only option that makes sense to the user. Disagree? The print spooler service was written by none other than Microsoft. If you hold firm to the opinion that no service should ever interact with the desktop, then you are calling Microsoft and the printer mfrs that write spooler components «inexperienced». If these developers were more «experienced», would print spooler developers do all user interaction through the event log?

There is no one to one relationship from one service to one user desktop. It started with terminal services on Windows Server and got to the Windows Client with Fast User Switching and remote desktop connections: Multiple users can log on to one Windows machine, each has a different logon session, a different windowstation and a different visible desktop. So which desktop should your service showwindows or message boxes on? Should it multiplex? And if two users click «Yes» and three click «No» how does that count?

Even without session 0 isolation services could only communicate with a user logged on to session 0. So when an admin used remote desktop to log on to a server he would only see those Service messages if he used mstsc /console which only one admin at a time could do. So guess how good this would work if two of those services must be administrated on one server by two different admin persons. They could not do their job in parallel.

The event log was only mentioned as the preferred way to be used instead of a console window to put status and error messages on, besides using a simple log file.

Launch services.msc, and a quick glance will show you numerous other services that must interact with desktops. Windows Update is one example.

I doubt that any Windows service from Microsoft uses this option any more. I checked Windows Update (on Windows 7) and it doesn’t.

And I doubt that session 0 isolation will go away. So I doubt that this «limitation» will go away.

IPC got really simple. With sockets and named pipes you had to implement quite some infrastructure to exchange commands and state. With COM it got easier and with .Net and WCF it has become really easy. Integrating into MMC is also nice with .Net. Just give it a try and you will never miss that «interact with desktop» thing a second anymore.