This document was created to help you get familiar with itopia + Google environment integration and configuration. It also contains some tips and few basic dos and don’ts for your deployment management. 

Detailed information about each topic is available in the below sections and links.
​

A portal that provides live information about itopia’s availability as well as details on uptime and past incidents. We want to communicate with clarity and transparency so you’re never left in the dark if things aren’t working as expected. 

Whenever there's an issue with our software or related services, we will let you know in the Statuspage. If you subscribe you'll receive live notifications about service outages, updates and scheduled maintenance via email or sms.

Google creates a default network per zone. Each one has a subnet size /20. These subnets cannot be modified at the provisioning. Changes in networking are not recommended. If any changes need to be done on the default network settings, it’s out of the scope of itopia CAS support.

Single servers should not be removed from the domain for correct functionality of the environment.
​

Firewall rules created at the deployment are the way for our software to communicate with your servers. We’ve already sourced the rules so only itopia management services can access the servers using those tags.

They shouldn’t be modified or deleted because such changes can break the integration with itopia. 

The main tags: cas-access, allow-access

You can open ports from itopia - Servers module, other changes can be done from Google Cloud Console. We recommend confirming with itopia support team before making such changes.
​

Itopia preloads certain set of policies for user management and security. The policies are created at the deployment. Every deployment includes Microsoft Office 2013 and 2016 ADMX templates which allow you to create your own set of group policies for Office management.

It’s not recommended to make any changes to the itopia preloaded policies but if absolutely necessary, inform itopia support team through the in-app chat to confirm the consequences of such changes.
​

Itopia creates the domain with standard OU structure for companies. It’s not recommended to move users or admins from the default OU because the itopia software will not be able to find those users in a different location.
​

In some cases the page file configuration can be set to just 1 GB. The best practice is to set the page file to be automatically managed by the operating system as described in the above guide.
​

The system creates domain admin accounts for every deployment that you send to Google cloud through itopia. 

Itopia creates an “itoadmin” domain admin service account for the itopia systems to be able to execute actions in your deployment's domain. The account shouldn’t be disabled, renamed or reset in Active Directory because the integration with itopia CAS will break.
​

Google sets certain limits to the usage of IPs and other resources (like CPUs, etc). It’s their way of protecting themselves against fraudulent accounts. Quotas on your account depend on your account usage history and the data center zone. Quotas should be monitored regularly since they can affect your deployments in itopia and the correct scaling functionality. In other words, if your quota is low, you will not be able to deploy new servers or increase server resources. Quotas can be increased anytime from Google Cloud Console. To check and increase your quotas, go to IAM & ADMIN from the main menu and select “Quotas”.
​

Autoscaling is the system’s ability to automatically increase or decrease your server count or server resources. By default, the autoscale is enabled on all deployments you manage from itopia and is based on end-user count. As you deploy more users or remove some, the system automatically adjusts the resources to the user count. You can adjust the system’s autoscaling criteria to your needs. To get even better experience scaling your environment, use images for autoscale.
In all itopia plans, you have the ability to disable the autoscaling and manage the resources manually. Make sure the autoscaling was disabled before changing the resources on session host servers.
​

The basic infrastructure servers (domain controller, user session server/ file server) are created during the provision. You can add other servers like App servers or SQL servers using itopia - Servers module. If you create new VM instances directly in Google, they will not integrate with itopia unless you import them using the server import feature (this option is recommended for non-RDS servers)
​

Google expands their data center network all over the world. There are 3 major ones in US: East 1 (South Carolina), East 4 (Virginia), Central (Iowa), West (Oregon and Los Angeles). You can test the latency to any datacenter here.

You can enable an RD Gateway and Redundant Gateway during the environment deployment. SSL certificate is needed for the gateway. If you are requesting a standard SSL, it should be requested for the hostname in following format: xxx.yourdomain.com where xxx is the deployment code that is automatically assigned to the deployment.
The best option is to request a Wildcard SSL, it's the most recommended option since it can cover unlimited host names (or subdomains) for 1 domain. You can even save on cost if you decide to purchase wildcard and then use the covered domain for all your deployments.
​

The uptime schedule runs according to every deployment’s time zone. We recommend to schedule the Domain Controller (pdc server) to turn on a little sooner than the rest of the servers to give it enough time to start the services and avoid it not joining the domain. Starting it 5-10 min before the rest of the servers should be enough.
​

Snapshots work great for the disaster recovery because they are able to save the entire VM image. It's recommended to also have a standard backup solution in place (e.g. VSS/ Windows backups) as an addition to Snapshots to be able to quickly recover files without reverting the disk back to an older snapshot or following a process of recovering a drive, attaching it to the server and removing it after the restore.

Snapshots can run anytime, however, for SQL servers it’s recommended to turn them off before running the snapshot in case there’s only one drive for the OS database and the logs. 

User profile configuration is taking advantage of the User Profile Disk (UPD) technology in Windows Server remote desktop services. Each user is assigned a virtual hard disk which will hold their profiles, including their home folders. You can disable UPD at the provisioning and in that case, you can configure other technology of your preference to manage user profiles.

Each user gets created with a logon script, it shouldn’t be modified in any way. It manages mapped drives and application shortcuts. If they are changed, the update might fail later when changes are made to the user account.
​

Applications must be installed on the terminal servers manually with command “change user /install” and when finished with command “change user /execute”.
Itopia helps you keep track of the installed applications through Tasks module and allows you to restrict them.
​

The permissions can be managed through itopia. Anything that’s under C:\Customer data can be managed through itopia Folders module. Other drives and locations are not integrated with itopia management portal.

Recommended migration practice: create the folder structure and security groups first and then assign all the permissions to the folders before moving the data in. You will get faster performance when the folders are empty and after dropping the data in, they will just inherit the permissions of the parent folders.
​

After creating a VPN, you will get billed according to Google pricing, itopia doesn't charge for VPN.
When a VPN is created, there is certain amount of time where multiple steps are taken on Google end (e.g assigning the IP). It’s happening in the background. Give the system 5 - 10 min. to finish the changes before testing VPN connection.