Now, for the first time ever from Microsoft, a new SharePoint farmstead on the framework from scratch is simply a few clicks away. This is symbolic in two ways, one, Microsoft is showing renewed commitment to an on-premise flavor of the platform. Two, for those who ever wanted their own SharePoint 2013 farm in the cloud in an easy and affordable manner, this is a great new option which was not available in the past.
There are two main options with Azure:
1. SP Farm (non-HA), with one DC or Domain Controller, single SQL server and a single SP server.
2. SharePoint farm (HA),with two DCs, a SQL AlwaysOn setup of a couple of SQL servers plus one File Share witness, and four SP servers.
In the simple farmstead set up, Azure will ask questions around what one wants to set up. It enables one to pick a domain name, serve account setting, size of servers and more. Upon clicking on the ‘create’ button, it would kick off the process to build a farm. This could take about two hours to complete. In the cloud platform wizard, it would ask for two accounts to set up, the farm account and setup account.
The wizard is nice enough to provision a second disk on the SP server. However, it does not actually put any files there. It requires manually moving the ULS log files and anything else one desires to the disk. When walking through the wizard, there is no option to move the Central Admin to a set port. Rather, the Central Admin gets provisioned on a random port, which is also the platform default, even though most people put it on a set port. Moreover, the Central Admin will get assigned to a public EndPoint in Azure so it is externally published without HTTPS. It is highly recommended to delete the EndPoint as soon as the farmstead is provisioned in order to make a more secure environment.
When building Virtual Machines, one is no able to choose Any Options from the agent. Microsoft turns on the BG information and Custom Script Extensions by default. However, if one wants to add any further extensions, it has to be manually done after provisioning the VMs. By default, WinRM is enabled for all virtual machines and assigned a public EndPoint. This is the default selection when creating a VM in Azure. However, it is a fairly common best practice to deselect it in order to close off the security hole. As there is no option to deselect this before the VMs are provisioned, it should be turned off manually after creating the virtual machines.
When checking out how the platform references the SQL Server, it is not using a Structured Query Language Server Alias or DNS Alias. One could have difficulty scaling the host out without this, thus, one should be cautious of the setup if scaling out is required in the future. The SQL data files and log files are on separate disks. This appears great, from the performance perspective, but not from the support viewpoint. Having the log files and data for any given database on separate disks is not supported and may lead to corruption of the data in case there is an issue with the Azure Storage Geo-Replication.