How to configure a simple push scenario?

[dadlMilestone]

Hello and first off I very much admire all the work that has been put into this project!!

I would love to be able to use it to manage multiple "environments" that have different configuration needs. The unique part of my situation is that these are all online virtual learning labs. Each environment is small, containing between 4-12 VMs running on a VMWare host. Some have domain, others do not.

My first scenario that I am testing in contains just two VMs, and I was thinking that since my environments are so small it would make sense to push the configurations, instead of setting up a pull server. I have no need for reporting, and the overhead (cost and resource) would make it impractical, I think. I have seen Microsoft documentation that describes setting up a simple SMB pull server, and that might be feasible in my situation as well.

Can you point me in the direction of any documentation that would describe how to set this up in my situation? I notice that the description of the project says that it generates all DSC artifacts for push or pull scenarios. I have successfully run build.ps1 and have the MOF and MetaMOF in my output folder, but am not sure how to apply it with a "push".

I can see that by default it sets up the LCM for a pull scenario with web and report servers and registration keys. What is the easiest way to remove that configuration, and allow for a scenario where I would take care of getting the required modules to the client, and then starting the DSC Configuration from the machine I'm using to build?

Maybe I shouldn't be using this Blueprint, since it is for medium and complex scope, if so, is there another project that allows for usage of the composite resources? I like the idea of being able to have the baseline config taken care of, and then mostly focusing on the unique configurations in my environment.

[raandree]

Since you have already managed to get the build working, I would continue to use this blueprint. Even for small configurations, the convenience provided by the build script and the Datum yaml model is very useful. Especially when building MOFs for multiple scenarios, the layered approach to defining configuration data is helpful.

How to use this project in a push scenario? The MOF files are identical for push and pull scenarios. For push, you do not need the Meta.MOFs. Just ignore them for the time being. You can push them the MOFs by using the cmdlet Start-DscConfiguration and point to the folder with the MOF files. The cmdlet tries to reach the computers via WinRM and via the name of the MOF file. You may want to give your nodes FQDNs if that help finding them.

[dadlMilestone]

Thank you for the informative reply. I have decided to do as you suggest, but also started with a fresh pull of the repository.

I am testing with two hosts, they are named "workshophost" and "workshopclient". They both have an administrator account with the same credentials. I am logged into the host/build machine with that administrator account.

I can get a successful build again. I also have hopefully configured the network settings correctly. I tested WinRM and it is available and accepting connections on both machines. I can run Enter-PSSession on the build machine (hostname: workshophost) and with no credential it can establish a session to the client machine (workshopclient) by hostname.

1. I run the command Start-DscConfiguration -Path .\Prod\ from the folder ~\Desktop\DscWorkshop\output\MOF
2. I see that the created job has failed.
3. I inspect the child jobs to get the errors.
   • The build/host machine says that the config is pending and I need to run the command again with the -Force parameter.
   • The client machine produces the error:

     The Powershell DSC resource DSC_xServiceResource from module <xPSDesiredStateConfiguration,9.1.0> does not exist 
     at the Powershell module path nor is it registered as a WMI DSC resource.
     

4. I run the command Start-DscConfiguration -Path .\Prod\ -Force and this time the client has the same error, and the host has a similar error, except the resource that it can't find is DSC_xServiceResource.

I have included a couple of screenshots that hopefully illustrate what I have explained above, in case it wasn't clear. The first screenshot shows testing out WinRM, getting TrustedHosts, and finally using Invoke-Command on the client to demonstrate ability to establish a PSSession.

The second screenshot involves running Start-DscConfiguration.

I hope that the errors are something simple, and it seems like they should be, so I am optimistic!

I am glad that you also think that it should be a good fit, as I was particularly interested in the granularity that the project provides which allows me to not duplicate my efforts. We have several different lab environments and I will be very happy to not have to maintain separate projects for each.

I have watched your Powershell + DevOps Global summit video regarding the workshop a couple of times, and am planning on attending this year in Bellevue, will you also be attending?

[PSD3vOps]

In a push scenario you need to provide the nessecary DSC ressource modules for the target node. In a pull configuration the pullserver is providing these ressources.

In your situation you could setup an smb-fileshare with the nessecary modules and point the LCM of your target node to the fileshare MetaConfig . The LCM of your target node knows then where to pull the modules from. Someone wrote a blog article how it can be done: Push-Config-Pull-Module

I think another option would be to deploy the modules beforehand to the target node through file copy operations.

[raandree]

Sorry for having lost track on this issue? Is there more help appreciated?