Hi, We have automated the installation of servers, and now want to use DSC. Because the just built server will not yet have a static ip and therefore not in DNS right away, we will use the uuid of the server for its .mof. I have already scripted the DSC client configuration for the new server, but now I'm on to the installation of software via the pull server.
Here is what I want to do, but I'm not sure of how to do it:
– after the server has been built, I will run a configuration script called InstallSoftware using $computername and $uuid which I supply.
But when I then copy the file to a uuid.mof (because I want the servername.mof to remain), the $computername and $uuid values are no longer valid, so the copy won't work. Also, I then cannot create the hashfile either.
So, how do I call the InstallSoftware config script with computername and uuid parameters, then be able to copy the file to another directory and create the checksum file?
Would someone please help?
I don't think I'm following what you're doing or asking ;).
Why do you have two MOF files? You know you can only apply one MOF via DSC, right? But you have two?
If you have servername.mof in C:\DSC, then you'd start DSC by running "Start-DSCConfiguration -Path C:\DSC". However, that command is going to try and remote into the server via Remoting, because that's how it works, even though the MOF is local.
What hash file are you talking about?
I think you might need to be a little clearer about what all these moving parts are, and what you're trying to do.
If the concern is, "the server won't be able to resolve its own name via DNS, because it isn't in DNS yet," then just name the MOF localhost.mof. If you run Start-DSCConfiguration on that machine, it'll connect to itself and start configuring.
If the concern is, "I'm trying to do a file copy by $computername and $uuid are no longer in scope," then you need to fix that. Do your file copy while those variables are still in scope.
This is a pull server scenario.
From what I understand, on the PULL server, I need to create a .mof file with the guid, or a fake guid, so that the client server knows what to PULL.
I have already configured that uuid name on the client in the the DSC configuration locally on the new server. That's not an issue. The client knows what .mof file to look for.
Yep, I do know that I can only have one .mof file, and that is all I would have. The original file would be called servername.mof and the one that would be used might be called 76AAFD9B-9388-45DD-B464-217A336E358.mof. The servername.mof file will just be sitting in some directory, ignored. It's there for my own logging, if you will.
So, the new 76AAFD9B-9388-45DD-B464-217A336E358.mof file – I was under the impression I need a checksum file as well.
Yep I'm trying to do the file copy while the variables are still in scope, but they are not there. I run the script (configuration, let's say I'm adding a feature) by calling it with parameters.
Or, cannot I not call the configuration file as a script? In otherwords, I need to call these dsc configuration scripts as scripts at the PS command line. Perhaps I cannot do this?
The bottom line I guess:
OK. That makes it a lot clearer.
In Pull mode, yes, MOF files are given a GUID. It isn't a "fake" GUID, it's just a GUID. One or more nodes are then assigned to pull that GUID. That configuration is done in the nodes' LCM. And yes, the pull server does need a checksum – New-DscChecksum can create one if you just give it the path of a MOF file. You can actually have it easily produce checksums for every file in the folder, so you don't actually need to know the MOF file name ahead of time. Just checksum everything!
I'd have to see that InstallSoftware script, then, if you can attach it. I do exactly this same approach and it works perfectly.
And my general approach looks like this...
Something like that. Assuming you're doing the same thing, if it isn't working, happy to have a look. Just attach it as a TXT file, we don't take PS1 uploads.
Ah, I think I have it, thanks for your help!
You must be logged in to reply to this topic.