January 5, 2015 at 11:00 am #21628
Hello and Happy New Year!
Working with DSC/Powershell V4 I have a few questions from a colleague: You can use the File resource to copy files from one destination to another, and ensure that the directories match. DSC seems to be a very boolean tool in nature that gives a lot of True/False.
Scenario 1: With LCM set to ApplyandAutoCorrect
Q1) How is the matching done? Is it by filesize, date modified, etc?
Q2) Supposing that there is a change to the source (we add a new version of a file or more files). Is there a way to increase the logging such that DSC will list all the files that get copied?
– Currently, when I activate logging (analytic) and I test this, I only see a "config drift" False result and that DSC moves to correct it. I do not see a list of what was copied "what was wrong".
Scenario 2: With LCM set to ApplyandMonitor
Q3) Kind of the same as Q2, only this time DSC won't actually 'fix' anything. The boss is 'hesitant' to leave the LCM as "ApplyandAutoCorrect" during times in which we are not deploying. He wants us to reset the LCM config before and after we deploy new versions of our websites. He does however see value in having DSC monitor for config drift, but if DSC won't list 'what files are different in the compare source vs dest.' in any logs then he's said that $true and $false is insufficient, and makes us lose a business case for using DSC.
Anyone here have an idea on changing the 'logging level' of the File Resource in DSC? Much appreciated!
January 5, 2015 at 11:24 am #21632
Q1) You can specify as part of the resource configuration – the Checksum setting. You can also specify various hashes.
Q2) Not super-readily. You could enable full-on diagnostics, but that's a LOT of logging, and it's not resource-specific. Because the File resource is binary, you really can't modify it. The point of DSC is more, "I trust you to make sure it's all taken care of" and not so much "keep a detailed list of what you did."
Q3) The intent of DSC is "is compliant or not," not so much "what's different." That changes in v5, where you do get the ability to compare configurations and get a delta report of sorts.
January 5, 2015 at 11:25 am #21633
The File resource is unique in that it's implemented as Binary (and as far as I know, it's a native WMI class, not even PowerShell cmdlets written in C#.) This makes it awkward to even see what it's doing, let alone make a community modification. I'll pass your questions about logging on to Microsoft via the MVP list and see if anyone can help out, but I suspect that changing this behavior (unless Microsoft does it themselves) will involve rewriting the whole resource from scratch. In PowerShell or C#, it'll probably not perform nearly as well as the native version, which may be why they implemented it that way in the first place.
For your first question, though, I can answer that. It depends on what value you set for the "Checksum" property in your configuration script. This property's name is a bit misleading, as you can also set it to values of "CreatedDate" and "ModifiedDate", causing PowerShell to use those values when determining whether a file needs to be copied or not. If you set Checksum to one of the other values (SHA-1, SHA-256, or SHA-512), the file is downloaded and cached, and then checksums on the cached copy and the destination path are calculated and compared. This is slower, but can also be a more reliable means of detecting differences. (It's possible to modify a file and also fudge its creation / modified timestamps, rather than letting the OS assign them.)
January 5, 2015 at 12:54 pm #21639
Thank you kindly Don and Dave! Very informative and I hope MS takes Dave's inquiry seriously and considers the logging aspect of the file resource. This will help us as we make decisions moving forward with regards to DSC.
You must be logged in to reply to this topic.