This topic details prerequisites for super tenant configuration.
A Super Tenant must have a perimeter network (e.g. DMZ in figure above) where DaaS tenant appliances and other external facing components like Unified Access Gateway are behind a firewall. The tenant administrator must create subnets for each customer to isolate. Each subnet must be labeled (typically with a customer id or name) to easily identify customers on hypervisors and the DaaS platform. The administrator must configure these subnets so that traffic is allowed between the DMZ and customer subnets (e.g. N1C1 and N2C2 in diagram 2.5) and vice versa. The Administrator can use either DVS (Distributed Virtual Switch) or standard vSwitch networks within vCenter. It may be advantageous to use distributed virtual networking since the number of VLANs per datacenter is limited according network specifications (4096 VLANs or less).
Tenant Active Directory and DNS Configuration
The tenant administrator can use a single Active Directory to serve all customers by creating customer specific security groups. The domain controllers and DNS server must be in the DMZ network so that all customer assigned subnets can connect. Please check Microsoft recommended best practices for use of domain controllers across subnets.
The administrator should create security groups for each customer to ease the user management and configuration in the DaaS platform such as user mapping. Customers can be separated by creating Organizational Units with security groups under the OUs in Active Directory.
Tenant DHCP Configuration
The tenant administrator should configure DHCP considering the network topology of subnets. A single DHCP server can be used to serve all subnet desktop clients by utilizing BOOTP-relay agent capability of a network router, or having another computer that can function as a relay agent on each subnet.
Each DHCP scope should be verified to ensure the correct domain controller and DNS configuration for each network subnet.
Please refer to Microsoft recommendations and best practices to configure the DHCP server: http://technet.microsoft.com/en-us/library/cc771390.aspx
The tenant admin should create a gold pattern and customize it per the customer’s requirement. The admin can create individual gold patterns for each customer if required.
Using a Windows client operating system image, such as Windows 7, in a Super Tenant may not be advisable due to Microsoft licensing restrictions. Specifically, the license associated with Windows 7 (also Windows XP and Window 8) requires that virtual instances run on isolated hardware per customer (e.g. Windows 7 instances for customer A and customer B cannot be on the same server or blade). A popular approach due to the licensing restrictions is to use individual Windows Server instances skinned as Windows 7. This approach gives the end user a familiar desktop look and feel and also allows sharing of infrastructure with SPLA licensing. For further information please refer to Microsoft Windows licensing for virtualization at microsoft.com.
The recommended way to deploy the DaaS Agent is to use tenant appliance auto discovery where a specific DHCP option code is used so that the DaaS Agent can automatically discover the IP addresses of the tenant appliances. In our testing we have found that auto discovery does not always work on subnets other than the subnet where DHCP resides. As an alternative the standby address can be manually set in the MonitorAgent.ini file.