I'm trying to create a configuration, using PowerShell DSC, that would help me create a SharePoint farm using Virtual Machines. Assuming that I have a Windows 10 machine with Hyper-V installed I would like my configuration script to create the required VMs, for example DC, SPA1, SPw1, SPW2 and SPDB1, configure their network connections and connect to a domain controller (DC1), then proceed to install the SharePoint/SQL Server prerequisites and installation before going on to configure the farm, once available.
I've created configurations that complete various stages but I am unable to figure out how to connect them to work in an orchestrated manor. For example I can create the VMs or perform the install and configuration of SharePoint but I can't get these configurations to work in tandem.
Having read the DSC documentation I thought that is might be possible using composite resources but I am unable to get the configuration to continue onto the new Virtual Machine after creation.
From the composite resource documentation:
configuration RenameVM
{
Import-DscResource -Module TestCompositeResource
Node localhost
{
xVirtualMachine VM
{
VMName = "Test"
SwitchName = "Internal"
SwitchType = "Internal"
VhdParentPath = "C:\Demo\VHD\RTM.vhd"
VHDPath = "C:\Demo\VHD"
VMStartupMemory = 1024MB
VMState = "Running"
}
}
Node "192.168.10.1"
{
xComputer Name
{
Name = "SQL01"
DomainName = "fourthcoffee.com"
}
}
}
Ideally the node names would be dynamically declared in the configuration data and not explicitly defined I.P addresses. I'm also having trouble with my Hyper-V configuration creating multiple switches but that's a separate issue. So I guess my question is:
Is it possible to create a configuration that deals with the creation and advanced configuration of Virtual Machines?
The problem you are running up against is a conceptual one of what DSC does.
Reading the document that you linked, it says
Configurations are declarative PowerShell scripts which define and configure instances of resources. Upon running the configuration, DSC (and the resources being called by the configuration) will simply “make it so”, ensuring that the system exists in the state laid out by the configuration.
DSC is designed to configure an instance of a resource. At its basic level a DSC configuration is run on a single machine, configuring that machine into a specified state.
DSC scripts should be constrained to work within the boundaries of the machine that they are running on. It seems that this is part of the problem you are experiencing.
If you have two sets of scripts. A Deploy VM script, that runs against a hyper-v server and a Sharepoint build that then configures the VM once it has launched. It seems that what you are trying to do is launch the Sharepoint script from within the hyper-v deploy script. At that stage though the Sharepoint server is outside of the boundary of control of the hyper-v server (apart from its atomic VM capabilities, start,stop, delete etc)
Instead what I would suggest you do is see them as two entirely separate entities. There is no need to have a scripted connection between creating a VM and installing Sharepoint.
At a high level your pipeline would look something like this
if \\server\share\sqlcompleted.txt exists
Or whatever other mechanism fits your environment. Building servers this way removes dependencies, it means that if you decide you want to switch to ESX then all you need to change is your deploy script. Equally if you move everything to a cloud deployment.