PowerShell Desired State Configuration (DSC) Journey – Day 3

I am going to keep including this statement on every blog until I remember it.  MOF stands for Managed Object Format.

When I left off yesterday I was oh so close to getting this working properly.  I realized at the end that I did something really dumb and had my Source Path set to my local hard drive, which isn’t going to work because the destination server isn’t going to be able to access it.  First thing I am going to do is fix that, because that was REALLY dumb and it’s been bothering me since yesterday when I left work.

Here is my current Configuration:

I run the Configuration from the ISE Console and then run the command TestConfig -ComputerName MyTargetServer and the .MOF file is generated.  Finally I run Start-DSCConfiguration -Path .\TestConfig -ComputerName -MyTargetServer -Wait -Verbose.  AND….ERRORS!

Well, my SourcePath is a Directory and it is accessible from the server in question (at least when I am logged in).  I do see an Access is denied message coming from the Target Server trying to access the share.  I am going to guess that’s caused by the fact I am using an Administrative share.  I changed the SourcePath to \\ServerName\Scripts\DSCTest.  I recompile (I am just going to call the process of running the Configuration and generating the .MOF that from now on.  It’s easier than typing that all out and I think most people will get the point) the Configuration and run it again against MyTargetServer.  Got the exact same error message.  Starting to get frustrated.  Maybe the File Resource can’t create folders in the root of the C:\ drive, which seems kind of dumb, but would also make sense from a security perspective (I guess?).  On MyTargetServer I create a Scripts folder and run the Configuration again.  Nope, same damn thing.  It occurs to me that maybe the order of the Resource properties might matter in this case, even though the TechNet article doesn’t say anything about that (and that would be incredibly dumb to do) so I re-order them to look like this.

Recompile the Configuration.  Try again.  Nope.  Same thing.  That’s it, I am changing Recurse to $False.  Recompile.  Try again.  And it works, although I don’t understand the logging at all.  With Recurse = $False, it created both the Scripts folder and the DSCTest folder (so I now have a C:\Scripts\DSCTest structure on MyTargetServer) but it obviously didn’t copy the PowerShell script I wanted.  Here is what the logging looks like.

So, a lot of the same errors about Access is denied, and that the path cannot point to the root directory or to the root of a net share.  BUT IT CREATED BOTH FOLDERS.  Which makes no sense to me.  Just for shits and giggles I turn Recurse back to $True and run the whole thing again with the file structure now in place.   Nope, back to the original errors.  I am baffled.  I check the security and sharing settings on my source folder.  While doing so, I realize the ComputerName I am using in my SourcePath is actually longer than NetBIOS allows, which is where all of the errors are coming from.  As an example, if the ComputerName for my SourcePath was \\JacobsTestComputer, NetBIOS has a 15 character max so I would have to shorten it down in my Configuration to \\JacobsTestCompu .  For the second day in a row I feel like an idiot.  Because after fixing that line in my Configuration and running it with Recurse = $True everything works exactly the way I expected it would.

All the pretty blue text makes me feel like I am winning.  To test this again I delete the directory structure on MyTargetServer and run the Configuration again.  Runs perfectly and everything is copied.  Now, I change Ensure = “Present” to Ensure = “Absent”.  Recompile and run again. Errors!

So far I am loving the usefulness of the error messages.  I add the Force = $True  property to my File Resource, recompile and run again.  I also comment out the SourcePath Property because I can’t imagine why it would be needed when you want to remove something.  Yahtzee!  Completed successfully, but it only removed the \DSCTest directory, it did not delete the \Scripts folder, which absolutely makes sense.  I run another test where I create the folder structure and remove it, but change the DestinationPath to just “C:\Scripts”.  The scripts folder and everything underneath of it is deleted (Although some I deleted it).  Here is what my Configuration to remove that folder structure looks like.  Important to note that I left the SourcePath uncommented in this example and DSC was smart enough to just ignore it.

One last thing I want to try and then I will call it a day.  I change  my SourcePath back to using an Administrative share, but this time with the shortened NetBIOS name and try to create the folder structure and it doesn’t work.  No Administrative shares.  Good to know.

Quick recap of things I learned today:

  • The order of the properties within a resource doesn’t matter
  • No using administrative shares for SourcePath properties
  • Don’t randomly pick a server with a name longer than NetBIOS allows to use as your testing SourcePath server!!!!!!!!!!
  • Force is required when setting the Ensure = “Absent”
  • Force requires a $True or $False

Thought I had immediately after this:  Is it possible to create a configuration that specifies what the root of a C:\ drive should look like?  That is, it only contains these 9 folders, and if a folder of any other name shows up, I want it deleted?  I will have to think about how to even approach that question, but that seems like exactly the kind of thing DSC was designed for.  I will either be pursuing that train of thought tomorrow or playing around with the rest of the File Resource properties.