VM Image ready for SharePoint Online Development

Question

Does anybody know a way to spin up a Virtual Machine in Azure that has SharePoint installed with Apps / Add-ins enabled? I'd like to have one image that has SQL Server SharePoint 2013 Server Onprem, Visual Studio all configured and ready for App development.

Answer 1

If you are searching for an "All-in-One" SharePoint developer environment premade template, I fear that Azure doesn't (yet?) provide that: all the options available from the "Create New Virtual Machine" gallery seem to be aimed at creating multi machine environment with no developer tools pre-installed.

This means that you probably will have to create your own "Template" for reuse. Sadly, this won't be simple nor produce perfect results.

You have basically two options: multiple clones of a base machine or attempt script a procedure that will produce preconfigured different machines in a replicable way.

Option A) - Clones The idea here is basically to create a base machine on Azure that is already configured to your needs. For those purposes it doesn't really matter how you create the machine. You could either start from a simple "Operating System Only" template and manually install what you need or try to upload a vhd image you already (maybe an Hyper-V machine) have to -Azure storage, it really makes no difference.
Once you have your base machine, you create an image of it from the Azure Portal management web site and then create "copies" of that image from the custom image section of the "New VM" section: this will create a replica of the original VM in the exact state it was when you captured the image (and since Azure yet doesn't provide something as basic as VM snapshots... you can see that this feature is very useful for testing purposes too, like testing a new service pack or cumulative update). There are at least to problems with this approach:

• Licensing: I am not really sure about how licensing works in this case. You end up with what for all purposes is a copy of an already installed machine, and since you never run sys-prep on the system... all the installed product are already activated too! While in some edge cases this may not be a problem - you could use the "By user account" VS licensing option and probably avoid the problem with SQL Server by using the developer edition... SharePoint is a whole different story. If you want to try this option, please check with some law expert beforehand.
• Resource Manager model VM. The new Azure portal introduces a new model called Resource Manager that can be used, and it changes many thing about how VM are grouped/stored/etc. Avoiding extensive details, the final result is that from the new portal you can't save VM images, and from the old portal you can't access Resource Manager model VM: to put it simple, you have no way to use the image approach with a "new model" VM, and the old portal is getting deprecated. What you can do instead, is manually copying the VM disk using a tool like RedGate Azure Storage explorer, and then an ARM template to create a new VM from a set of existing disk (Search for "VM from specialized disk set" in the github Azure Resource Manager Templates repository). I have used the approach to migrate some old Hyper V machines to Azure, so it should work with this approach too. The same consideration about licensing still apply, though.

Option B: Scripting The idea is to script a full SharePoint install and then run the script whenever you need. There are multiple tutorials online about doing so, so I won't go in much details. You probably want to use something like AutoSharePoint-Installer to automate the SharePoint installation process, and you will need to script the install of all other required software/features too (AD promotion, SQL server install, Visual Studio...). The script could be then attached to an ARM deploy template to be automatically run after you create a base operating system only VM. This shouldn't technically violate any license, but it will be pretty difficult to implement. Also, take in account that every time you need a new VM, the deploy process will create a new one... so you will have to wait for the installation process to be completed, and that could take some time.

In the end, you probably should ask yourself how many VM copies you are going to burn/kill during your test/developments and act accordly. Consider automating the creation only if you expect to need many VM in a short time period, otherwise you probably will be good with creating a new VM every time manually.