Workspaces Frequently Asked Questions



I have a new Workspaces deployment and I see Organizations, Workspaces, and Clouds on the main menu, what are these and how do they interact?

Let's start with a diagram and then explain how each of the object within that diagram interact. Diagram 1 and Diagram 2 should help you better understand.

Diagram 1 – Single Organization with two Workspaces in two clouds



Diagram 2 – Three Organizations – growth to greater scale



What is a Cloud?

A cloud consists of a pool of compute resources, items such as physical servers (CPU and RAM), storage, and networking, are the key items which are included in a Cloud. You can think of a Cloud in terms of individual Datacenters, for example Austin, Las Vegas, or even a Customer’s own hypervisor-based deployment at their premise. It can also be as simple as a Resource Pool within a shared VMware Virtual Center.

A Workspace exists on a Cloud because it is taking advantage of the compute resources which are provided by the cloud.

As you’ll see in the diagram 1 above, a Cloud never intersects an Organization, this is because an Organization is a logical construct and has no relationship to anything physical.

It is also important to understand that a Cloud can host many Workspaces on it, for many different customers, this is shown in Diagram 2 above.


What is an Organization?

An Organization is a directory of Users, Groups, and Workspaces which are members of it. It does not exist in any specific Cloud. In fact, an Organization is part of an Active Directory and its Users, Groups and Computers are derived from, and stored in Active Directory. Because it is part of an Active Directory it doesn’t exist in any one site or Cloud.

Notice in both the diagrams above, an Organization never touches a Cloud, however, an organization does intersect with a Workspace because an Organization is providing access, via permissions, to resources within a Workspace. You could even say an Organization “owns” a Workspace, but an Organization never “owns” or is never “owned” by a Cloud.

Ultimately an Organization provides permissions to its Users to access resources in a Workspace including Applications, file shares, virtual machines, and User Profile Disks.

An Organization can have multiple Workspaces associated with it, and each of those Workspaces can be on different Clouds.

For example, as shown in the diagrams above, Organization Acme Company can have a Workspace A on the Austin Cloud, and a Workspace B on the Vegas Cloud. This concept means that a user, which is a Member of the Acme Organization, can access resources in both Workspace A and Workspace B at the same time.


What is a Workspace?

A Workspace is the junction between a Cloud and an Organization. It is the logical container where objects such as Virtual Servers, Mapped Drives, App Store, and User Profiles are presented.

A Workspace has no physical presence, all its objects are virtual; rather, a Workspace utilizes the physical Cloud’s resources (CPU, RAM, networks, and storage) to deliver compute capabilities via Virtual Servers. The Workspaces objects, again Virtual Servers, Mapped Drives, App Store, and User Profiles, are then utilized by a user based upon the permissions granted to the group(s) the user is a membership of within their Organization.

A Workspace can only be on one Cloud and can only be associated with one Organization. In addition, an Organization cannot have more than one Workspace on any one Cloud.


What is a Service Provider?

A Service Provider is the top-level Organization in Workspaces. While the Workspaces graphical user interface is not laid out in a tree format, you can visualize it as a logical tree.

The Service Provider is the first Organization and is created when Workspaces is initially configured. Just like any other Organization it is associated to at least one Cloud and has at least one Workspace.

A Service Provider Organization is a member of a Shared Active Directory Domain, and as such is contained within an Organizational Unit (OU) in the Active Directory. In fact some of the Service Provider users are frequently included in the Domain Administrators group.

You can learn more on what a shared Active Directory’s function is found under the section titled; What is the difference between a Shared Active Directory, a Dedicated AD, and a BYOAD (Bring Your Own Active Directory?),

Since the Service Provider is the top-level Organization its Administrative users have full rights over the whole Workspaces environment including all Clouds, Workspaces, and Organizations.

To fully understand what a Service Provided is you must understand the different types of Domains, but always remember, the Service Provider Organization is a Shared Domain, multi-tenant, and it's the first domain that was created!


What is the difference between a Shared Active Directory, a Dedicated AD, and a BYOAD (Bring Your Own Active Directory)?

There are three types of Domain that can be created within Workspaces:

  1. Shared – this type of domain allows multiple future tenant Organizations to share the same domain. New Organizations will be created as Organizational Units (OU) within the Shared Active Directory. Two things to note:
    1. The Service Provider domain is a Shared Domain. The implication of the Service Provider Domain being shared is that you can easily add additional Organizations (frequently referred to as companies or tenants) without having to create new Active Directory domains.
    2. You can create additional shared domains. For example you could create a shared domain named baddog.local for a partner, and then they would be able to have multiple organization share this Active Directory domain. This would allow them to manage their own Active Directory separate from the Service Providers Active Directory.
  2. Dedicated – this type of domain is dedicated to only ONE Organization and cannot be shared. It is NOT possible to create additional Organization within this type of Domain. It is a one to one relationship only!
  3. BYOAD – Bring Your Own Active Directory – this type of Domain is special because it connects to an existing domain that the customer provides, or as the name implies “brings with them”. This type of Domain is a dedicated domain and can have only one Organization associated with it, the original Organization from which it was derived. This type of domain can either be located all within the Cloud site, or it can be a Hybrid with a Domain Controller at the customer site and a Domain Controller in the Cloud site. Generally, the Hybrid type requires a VPN tunnel to connect the sites and has special requirements to design the Sites and Services with in Active Directory to facilitate near instant replication. Workspaces requires the domain must be either 2012 or 2016


The images below are visual depictions of an example Workspaces Organization and domain structure. Both images show the exact same information just laid out in a different format.

The Service Provider, Training Company, is in the shared Active Directory, training.local. Also, within this Domain are two tenant organizations Acme Company, and Beta Company.

In addition to the Service Provider’s shared Active Directory there are two additional domains. The first is a Dedicated Domain named epsilon.local and the only Organization within it is Epsilon Home Décor.

Finally, the third domain, redwagon.local, is another shared domain which has three tenants utilizing it.



Do I need to have a new Active Directory created for every new Workspace I create?

No, Active Directories are associated to Organizations not Workspaces. Each Workspace must be associated to an Organization, and an Organization must be part of one of the three types of Active Directories.


Do I need to have an Active Directory for every Cloud?

No, Active Directories have nothing to do with Clouds. Remember an Active Directory is equal to an Organization which have no location requirements.

However, an Organization (AD) can stretch across multiple Clouds (sites). As a result of that type of design you will be creating a new Workspace for an Organization which now exists within two Clouds. Therefore, it is recommended to have at least one domain controller in each of the  Clouds to support the virtual machines in that Workspace. Think of this in the same way Microsoft Active Directory Sites function.


Do I need a new Active Directory for every Organization I create?

It depends upon the business need and the type of Organizational domain you plan to use.

If you require a Dedicated Active Directory domain to support an Organization, then yes you will have at least one AD Domain Controller for that Organization.

If it is a BYOAD (which is essentially a dedicated domain) then yes you will have a at least one AD for that Organization.

If it is a Share Active Directory, then many Organizations will share that AD, therefore, the Organization is created as Organizational Unit within the Active Directory.


If I have a company that is worried about the security of its users what type of AD should I use?

Dedicated Active Directory would be the best choice.


I have a company that has a very mature network, including an existing Active Directory with lots of of users, and lots of Access Control Lists (ACLs) applied to resources, what should I do?

You would consider using a BYOAD so that you can import those users into Workspaces. By doing this you can easily create a hybrid solution with some resources in the Cloud and some remaining at the customer’s premise.


If I have a dedicated AD or a BYOAD what extra resources do I need?

Of course, you will need at least one Domain Controller in the Cloud for Workspaces to utilize. Workspaces requires the domain must be either 2012 or 2016. In addition, each Domain requires an RDS Application Gateway and this requirement is because the App Gateway must be joined to a domain.


What type of domain do you support?

Workspaces supports either a functional level of Window 2012 or Windows 2016 domains. Windows 2008 and before are not supported, nor is any version of a Small Business Server domain supported.


What operating systems does Workspaces support for member servers?

Workspaces supports either Window 2012 or Windows 2016 server. Windows 2008 is NOT supported.


I already have Terminal Servers that work very well, and I do not want to rebuild them, what can I do?

If they are Windows 2012 or Windows 2016 virtual servers, you can easily clone those servers to a template. Once in template format you can import them into Workspaces and use them to create new session host images and deploy applications or desktops.


I have additional Line of Business servers (LOBs), for example SQL, Exchange, or an application specific server what can I do?

Workspaces does not need to manage these types of servers so you can either simply place them in the same network and they will behave like normal, or if you want you can import them into Workspaces. However, imported LOB servers, since they were not built by Workspace, will have limited management features.

Existing file servers have complex issues and they will need to be specifically covered during the design of a Workspaces deployment. See the FAQ, “What about my fileserver?”.


I know I need to have a network for my customers VMs, do I need to have a network for every customer, or can I share one network?

The answer is it depends. Here are things to consider:

  • Networks have nothing to do with Organizations, they are created on Clouds and used by the Workspaces on that Cloud. In a flat network design it is possible for multiple Workspaces to share the same network.
  • If an existing Organization will be adding a new Workspace, which will be hosted in a new Cloud, then yes you will need to have a new network.
  • If you are creating a new organization, and you plan to use the Service Provider’s shared domain, and the associated Workspace is in an existing Cloud, and network security is not a concern, then you can use the same network for multiple customers.
  • If you are creating a new organization, and the associated Workspace in an existing Cloud, and you plan to use the Service Provider’s shared domain, BUT network security is a concern, then you should create a unique network for that Workspace and link it to a unique port group subnet. You will want to take into consideration the need for a new DHCP scope, and additional firewall/routing configuration, to support this network.
  • If you are creating a new Organization, with a new Domain which by definition must also include a new App Gateway, then yes you need to create a new network. You will also need firewall rules including DNAT and SNAT rules, a pubic IP address (or port forward), and public DNS entry.
  • If you are going to be adding an Organization with a BYOAD, then yes you need a new network. You will also need firewall rules including DNAT and SNAT rules, a pubic IP address (or port forward), and public DNS entry.


What about my fileserver?

A fileserver is a unique object within Workspaces. If a fileserver is built by Workspaces it is given a special role and can be used to create file shares, mapped drives, and User Profile Disks. If the fileserver was not created with in Workspaces you cannot manage those types of items from within Workspaces. However, if it is a requirement that you keep a previously created fileserver you can still use Group Policies and other standard network techniques to manage it. This topic should be addressed when planning a Workspaces deployment.


When would I need to have a new Cloud?

There are two reasons why you would need a new Cloud, they are:

  • You are adding a New Datacenter, or you wish to connect to a Customer’s cloud deployment (this could be a P-Cloud or a Cloud at the customer’s premise). Under these scenarios the following new resources will need to be provided and utilized by Workspaces:
    • Physical hosts and the associate CPU and RAM used for compute will be provided.
    • New networks will be created and made available for Workspaces to use.
    • New storage volumes will be presented to the environment.
  • You want an enhanced security boundary which can be used to provide a specific tenant Organization increased permissions for elevated control over their Organization and Workspace. In this case the cloud DOES NOT have to be a unique physical datacenter (although it could be in which case both this and the above scenarios apply), rather it could be a cloud which is created using a properly deployed Resource Pool within a shared vCenter. Once a Cloud is created for this purpose permissions can be applied at the Cloud level for the specific Organization’s users, which, will allow for greater control and enhanced permissions for the Organization's administrative user(s).


For example, you have created a new “dedicated” Cloud for the Organization Acme where they will be the only tenant using the Cloud. Because the Cloud will be dedicated to only that Organization you can provide elevated permissions to their delegated administrative users. This will allow those users to do tasks such as manage the virtual machines within the Workspaces associated to their Organization on that Cloud.


Keep in mind a new Cloud also means:

  • You will be required to build a new App Gateway to provide access to the Workspace resources being delivered from this Cloud. This is required even if the new Cloud is simply a resource pool in an existing datacenter.
  • If the new Cloud is in a remote datacenter you will need to consider how you will connect resources together, Active Directory is the most relevant, with the most common method being a VPN tunnel.
  • If the new Cloud is for Organization which is part of an existing Active Directory, then you will need to determine if you want (it is highly recommended) a Domain Controller to service resources in that cloud. If so you will want to use Active Directory Sites for proper architecture per Microsoft best practices. It is not required that you have a Domain Controller in a remote Cloud, however, is it strongly recommend for greater resiliency and performance.
  • Under some scenarios you may not need to connect the Clouds together. An example where no inter-cloud connectivity is necessary would be a Cloud which is created for one Organization, with an AD dedicated to only that Organization, and that Organization has only a single Workspace which it is located on that Cloud. In other words, you would not need a VPN in this case.
  • You will need new networks, and storage, dedicated to the new cloud. This is true even if the Cloud is only a resource pool dedicated to a customer because you do not want cross pollination of virtual machines.


I have my own instance of Workspaces, therefore, I am the Service Provider. I have a new customer that is not concerned about Active Directory security and they are very cost conscience about having to pay for unnecessary virtual servers. What should I do?

You should build them a new Organization within the Service Providers Active Directory. You will also build them a new Workspace with an existing cloud. In this scenario they will then be able to share the AD services and the App Gateway. To do this refer to the following KB documents:


I have my own instance of Workspaces, therefore, I am the Service Provider. I have a new customer that is VERY concerned about Active Directory security and they are very cost conscience about having to pay for unnecessary services. We will be using an existing Cloud. What should I do?

You should build them a new Organization utilizing a Dedicated Active Directory. Because they will have a Dedicated Active Directory server, they must also have a dedicated App Gateway server, unfortunately adding a new Domain will cost extra due to the added security. You will also build them a new Workspace within an existing cloud. To accomplish this refer to the following KB documents:


I have my own instance of Workspaces, therefore, I am the Service Provider. I have a new customer which has a mature network with an existing active directory and does not want to rebuild everything and all their users into a new AD. What can I do?

In this case you will create a new Bring Your Own Active Directory (BYOAD) which will be a dedicated domain for this customer. You will import the customer’s existing Active Directory so that you can “invite” the users to join Workspaces. The invite should be in the form of an email so you will want to be sure you have email addresses on the user’s AD Accounts.

Additionally, servers that exist today in the customers network can be brought into the Workspaces environment and any existing Terminal Servers which are used to deliver desktops or published applications can be imported.

There is a very specific process for accomplishing this scenario and many variables to consider during the Workspaces design. You will need to review and follow the steps in all the following KB articles


What are these things called “templates” used for?

A template is the starting point for any virtual server that is built within Workspaces. This is true whether it is a standard Windows server you will use for a LOB, a Fileserver, or a Session Host. The benefit of using templates is the consistency it offers when deploying servers, this is frequently referred to a “Gold Image”. You will have many different templates in the environment, and each template can be customized for a specific purpose or customer.


What is a session host?

A session host is a server, or group of servers known as a collection, which will allow users to either connect to “published applications” or a virtual desktop. This is also commonly known as a Terminal Server, or Remote Desktop Services (RDS). In Workspaces a “session host” has a specific meaning which is based upon two factors; how the session host is created, and how the management lifecycle of the session host is performed.

  1. A session host, whether it is an application host or desktop host, is always created from a “gold image” template. The template has applications installed in it, along with other custom configurations, and is then used to create new servers. This provided consistency and simplifies change control.
  2. If you wish to add new applications to a session host collection you must use a specific process to install the applications, and then “republish” the session host collection with those new applications installed. The republishing process will create new servers with the new applications, and once that process is complete Workspaces will delete the old servers that lack the new applications. One important feature is that new servers are created using automation, and if there is more than on server in the collection, then the workflow process recreates all the servers automatically from the same gold image.


What is a persistent session host?

Like a session host a Persistent Session Host (PSH) is created from a template, but the difference is in the lifecycle management of the PSH. Once a PSH has been created it is never deleted, it is persistent, therefore, if you need to add new applications you must install them directly on each of the PSH servers in a collection by hand. This method is the more traditional method of managing servers because you must adhere to strict change control rather than rely on a gold image to ensure the servers have the same configuration.


When would I use a session host versus a persistent session host?

The most common reason to use a PSH versus a standard Session host is when an application has certain requirements, licensing is common, where destroying a Session host during the republish process causes information to be lost, thereby, requiring the reconfiguration of a system by hand. Since this is obviously not ideal a PSH over comes this problem.


What is a User Profile Disk (UPD) and why would I want to use it?

A UPD is a method of storing User Profile Data to ensure a consistent and smooth end user experience. This is valuable when a user will be accessing a pool of session hosts, and storing a local profile is not ideal, because a local profile will not roam with the user when connecting to different servers. User Profile Disks are always used in conjunction with Folder Redirection to ensure a user’s data is stored in a centralized location where it is always available to the user, and it is secured and backed up.


How do I setup UPD and folder redirection?

To use a UPD and folder redirection you must first setup a fileserver which is provisioned utilizing the Workspaces system. The reason you must use Workspaces to build the license server is because it is given a specific role within the Workspaces system.

One you have a fileserver setup you will want to add an extra logical disk to the virtual machine which is enough in size to store the user data. You will do this on the virtual machine within Workspaces. Every organization will have different requirement for this, Microsoft specifics the minimum UPD size is 20gb per users. In addition, you must consider the amount of data that will be stored in the users redirect folders.

Once you have provisioned the new disk you will need to provision a new file share on the fileserver which again needs to be done in Workspaces so that this files share will be visible to Workspaces for this specific purpose.

Finally, you will run the workflow which will configure both the UPD and redirected folders. This is located within each individual Workspaces. settings tab.

After you have created the UPD you will want to test it by creating a user, logging with that user, logging out, and then going to the fileserver and validating a new profile and redirected folders location was created.

0 out of 0 found this helpful



Article is closed for comments.