Published apps, printing and reports for virtual desktops

Three sections of an adopted Remote Desktop Services (RDS) deployment's page answer the questions customers ask most after "is it up?": who can open which app, why printing is slow or broken, and whether they have the right number of servers. Open Infrastructure > Virtual desktops, then the deployment. If you have not adopted it yet, see Virtual desktops: finding and adopting deployments.

Published apps#

The Published apps section lists every RemoteApp program and each session collection's full desktop, read from the connection broker every 30 minutes, at once with Read now, and after every change made here. For each one you see its Name, whether it is a Desktop, Hidden or Switched off, the collection it is Published from, who it is Assigned to (groups and people as RDS names them, or its collection when it has no groups of its own), the group it is Given through and its File types.

Giving and taking away access#

Access is group-driven: rather than adding people to RDS one by one, Tenvara adds them to the group that gives the app, so the change is visible in Microsoft 365 and Active Directory as well.

1. On the app's row, check Given through names the right group. If the app has several, choose one; it is remembered.
2. Open the row's menu and click Give someone access (or Take access away).
3. Choose the people and click Continue.
4. The Microsoft 365 change dialog shows exactly what changes, with its approval and Undo, before it runs. For a group synced from Active Directory the change is made in Active Directory, which is what RDS reads.

Note: RDS takes Active Directory groups, so connect the customer's Microsoft 365 tenant with its groups synced from Active Directory. Without a connected tenant the section shows who gets each app as RDS names them, and Give someone access is not offered.

The automation step Virtual desktops: give or take away a desktop or app does the same from a rule, so a new starter form can grant a desktop. See Actions.

Publishing and changing apps#

• Publish an app: choose the collection, An application or A desktop, the Name people see, the Program (its full path on the session hosts), an optional Command line, Folder and File types it opens, and For the group (optional).
• Change: the same fields, Shown to people and Switched on. File types become exactly those you give.
• Assign a group: This program only, or The collection (every program in it without groups of its own). Removing the last group puts a program back on its collection's groups; the dialog says so.
• Unpublish: nobody can start it any more; people already in it stay until they close it.

Publishing, changes and group assignments wait for an approval when Published app changes wait for an approval is on (it is by default) in Settings > Infrastructure, the Virtual desktops section. Unpublishing always waits for one.

Warning: RDS makes these changes on every session host of the collection. Add the broker's computer account (DOMAIN\BROKER$) to the local Administrators group on each session host, for example with Group Policy Restricted Groups. Without it Tenvara checks each host first, changes nothing and tells you which host refused.

Printing#

Printing is the usual reason people on a shared session host ring the service desk. The Printing section is read from each session host's agent every 15 minutes (or with Read now) and shows:

• Sessions with failed printers, Hosts read, Hosts with third-party drivers, Spooler crashes today and Print servers down across the top.
• Findings, each with where it is and a Fix: line. For example: the Print Spooler not running; the spooler crashing, with the driver it crashed in; third-party printer drivers on a session host or running inside the spooler; printers that failed to map; mapping printers slowing logons; and print servers that are down or not monitored.
• Mapping by pool: per collection, the sessions read, those with printers, those that Failed to map, the Middle mapping time and the Printers that failed.
• Session hosts: the Print Spooler, Crashes today and the module they were in, Third-party drivers and the Driver isolation policy.
• Printer drivers on the hosts, third-party first, with whether each runs Inside the spooler or Isolated.

Each session also has a printer badge (Printers mapped, Mapping failed, Slow to map or No printers) in the Sessions table. It opens the session's printers (Redirected from their device, From a print server or On the host), the ones that failed with the driver they wanted, and how long mapping took after logon.

Tip: Third-party drivers on session hosts are the commonest cause of spooler crashes. The fix line suggests Remote Desktop Easy Print first. If a customer needs a particular driver, add it to Printer drivers allowed on session hosts in Settings so it stops being a finding.

Three alerts cover the worst cases: "Print Spooler down or crashing on a session host", "Printers failing to map on virtual desktops" and "Virtual desktop print server down". Their thresholds are in the Virtual desktops section of Settings > Infrastructure, with Printer mapping is slow at logon over (10 seconds). General printer work (deploying printers, drivers and toner) is in Printing.

Usage and reports#

Every read of an adopted deployment's sessions is kept by the hour for Keep virtual desktop history for (400 days by default).

The Usage section#

Pick a Period of 7, 30 or 90 days to see Most sessions at once, Average daily peak, Most people at once, the Median logon (with "95% within" a time), Most licences in use, Cost and Rightsizing, with charts of sessions at the busiest hour each day against what the hosts take, and licences in use each day.

Cost comes from each session host's purchase cost in Assets, written down per month.

Rightsizing#

A collection needs a day of history before any suggestion appears. Tenvara suggests:

• fewer hosts when one never had more sessions than Suggest fewer hosts when one never has more sessions than (2), or when the busiest hour needed fewer hosts than were available, keeping Hosts to keep spare at the busiest time (1), with the monthly saving where costs are known;
• more capacity when the busiest hour reached Suggest more capacity when the busiest hour reaches (90%) of what the available hosts take.

Reports#

The report builder has a Virtual desktops group of ready-made reports that run, schedule, export and send as PDF like any other: Virtual desktop session peaks per day, last 30 days, Virtual desktop peaks by collection this month, Virtual desktop licence use this quarter, Virtual desktop logon times per day, last 30 days, Slowest logons by host, last 30 days, Slowest logons by person, last 30 days, Virtual desktop utilisation and rightsizing, last 30 days and Underused hosts. See The report builder.

The monthly customer report has a Virtual desktops section with each deployment's busiest time, daily peaks, licences, median and slowest logons and the rightsizing suggestions. It is left out when nothing was recorded that month. See Monthly customer reports.