Cannot re-register node after using ConfigurationId when switching back to ConfigurationNames

[kamranayub]

WMF5, xPSDesiredStateConfiguration upgraded from 3.7 to 3.9 (switched to ESENT database).

I had previously had a successful pull client enrolled in my pull server when using partial configurations--i.e. it was able to pull config and update itself.

I've since been testing Composite Resources instead of partials, so I'm now trying to switch the pull client from using a ConfigurationId + Partial Configurations to using a ConfigurationNames now. Instead of multiple MOF files, I now have a single MOF file ("TestConfiguration.mof").

When I run the LCM configuration against the pull client, this is what I get back:

Registration of the Dsc Agent with the server https://pullserver/PSDSCPullServer.svc failed. The underlying error is: The attempt to register Dsc Agent
with AgentId 1C4637FD-7E90-11E5-8124-005056A4CA09 with the server
https://pullserver/PSDSCPullServer.svc/Nodes(AgentId='1C4637FD-7E90-11E5-8124-005056A4CA09') returned unexpected response code NotFound. .
    + CategoryInfo          : InvalidResult: (root/Microsoft/...gurationManager:String) [], CimException
    + FullyQualifiedErrorId : RegisterDscAgentUnsuccessful,Microsoft.PowerShell.DesiredStateConfiguration.Commands.RegisterDscAgentCommand
    + PSComputerName        : lab-pull-client

So, it applied the configuration fine (LCM: [ End Set ]), but when trying to register the node, it fails.

I also checked the EDB file with ESEDatabaseView and see that no devices are registered in the database:

What could be causing the failure to register? The Agent ID was originally provisioned when I first set up the pull client (with partials). Could that cause it? Is there a way to reset the AgentID (remove it) and "start from scratch" with the LCM? Is there a way to see exactly what is going wrong? The event logs don't necessarily share anything interesting except that it can't send a status report (NotFound) since the device isn't registered.

I still need to test enrollment with a blank VM--to see if a brand new client can enroll without issues.

[ArieHein]

ConfigurationNames only works with AgentID registration, not ConfigurationID

[kamranayub]

Yes, sorry maybe I wasn't clear. I am using agent registration with configuration names currently, but when it was working I had been using configuration ID and partials. Currently, the same node is not working with agent registration and names.

On Mon, Apr 18, 2016, 07:32 Arie Heinrich notifications@github.com wrote:

ConfigurationNames only works with AgentID registration, not ConfigurationID

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/PowerShell/xPSDesiredStateConfiguration/issues/110#issuecomment-211359162

[ArieHein]

will have to see your pullserver and lcm scripts to see how you set it up to try and figure out why its not registering. I assume youre using 3.9.0.0

[kamranayub]

Yes, 3.9.

The LCM meta config that gets generated (and applied) to the target node is pretty straightforward:

/*
@TargetNode='lab'
@GeneratedBy=MYUSER
@GenerationDate=04/20/2016 12:20:36
@GenerationHost=MYPC
*/

instance of MSFT_WebDownloadManager as $MSFT_WebDownloadManager1ref
{
SourceInfo = "foo.ps1::52::9::ConfigurationRepositoryWeb";
 ServerURL = "https://pullserverhost/PSDSCPullServer.svc";
 ResourceID = "[ConfigurationRepositoryWeb]PullServer";
 RegistrationKey = "GUID";
 ConfigurationNames = {
    "Sandbox"
};

};

instance of MSFT_DSCMetaConfiguration as $MSFT_DSCMetaConfiguration1ref
{
RefreshFrequencyMins = 30;
 RefreshMode = "Pull";
 RebootNodeIfNeeded = False;
 CertificateID = "PUBLIC KEY";

  ConfigurationDownloadManagers = {
  $MSFT_WebDownloadManager1ref  
 };
};

instance of OMI_ConfigurationDocument
{
 Version="2.0.0";
 MinimumCompatibleVersion = "2.0.0";
 CompatibleVersionAdditionalProperties= { "MSFT_DSCMetaConfiguration:StatusRetentionTimeInDays" };
 Author="MYUSER";
 GenerationDate="04/20/2016 12:20:36";
 GenerationHost="MYPC";
 Name="PullClient";
};

[ArieHein]

Though its not the scripts needed, and the pull server one is missing, your LCM mof file seems ok, so i dont think its the LCMs fault. The pullserver script link might help in finding the problem.

Did you delete the old pull server web site, app pool and files (including the devices.mdb local database) from the IIS and rebuilt the pull server ?

Note that according to the LCM mof file you linked, the mof file on the pull server should be named Sandbox.mof and not the initial "TestConfiguration.mof" you noted on the first post.

The AgentID is regsitered in the windows registry at: HLKM\Software\Microsoft\DesiredStateConfiguration Even if you delete the value of the AgentID key, the LCM will still hold it as its in the memory. Getting a new AgentID can be achieved by running Get-DSCLocalConfigurationManager But the registration process does it too, which gives the node its initial AgentID

[kamranayub]

Thanks, I will try playing with it. I enabled Failed Request Tracing and saw the failed PUT request returning a 404. It's almost as if it is not trying to register, unless that is what the PUT does.

Yes, I deleted the pull server website files, upgraded to 3.9 and switched to ESENT, so it is blank.

On Thu, Apr 21, 2016, 01:42 Arie Heinrich notifications@github.com wrote:

Though its not the scripts needed, and the pull server one is missing, your LCM mof file seems ok, so i dont think its the LCMs fault. The pullserver script link might help in finding the problem.

Did you delete the old pull server web site, app pool and files (including the devices.mdb local database) from the IIS and rebuilt the pull server ?

Note that according to the LCM mof file you linked, the mof file on the pull server should be named Sandbox.mof and not the initial "TestConfiguration.mof" you noted on the first post.

The AgentID is regsitered in the windows registry at: HLKM\Software\Microsoft\DesiredStateConfiguration Even if you delete the value of the AgentID key, the LCM will still hold it as its in the memory. Getting a new AgentID can be achieved by running Get-DSCLocalConfigurationManager But the registration process does it too, which gives the node its initial AgentID

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/PowerShell/xPSDesiredStateConfiguration/issues/110#issuecomment-212768663

[kamranayub]

@ArieHein where are the DSC pull server trace events written to? Is it in one of the event logs? I'm referencing the caught exceptions and such. I'm wondering if maybe the pull server can't write to the ESENT database or something deeper.

[kamranayub]

Turned out to be totally unrelated, our IIS configuration was preventing PUT and DELETE at the application host-level. As soon as I allowed those verbs in the web.config, it worked.

Thanks for your help!

[dotps1]

@kamranayub can you give a little more info how you fixed this PUT and DELETE issue?

[kamranayub]

@dotps1 IIS by default doesn't restrict verbs but it turned out our base image for web servers internally blocked some verbs.

You can find out if that's the case by going to IIS Manager. The rules can be added to the Server level or Website level, so might want to check at the Server level first (the first tree node) and then check an individual website.

Go to Request Filtering:

Then HTTP Verbs:

If there's any in the list, then someone's modified the defaults.

Also, keep in mind if you're working in a internal environment, a firewall could also be blocking requests to the web server (or even the Windows Firewall, if you haven't configured it to allow HTTP/HTTPS traffic). It's a good idea to rule that out by enabling Failed Request Tracing, and making sure that some trace files are generated for bad requests. You could also use a tool like Wireshark or Microsoft Network Analyzer to trace packets--but if FRT files are generated, it means requests are coming through.

[dotps1]

yeah, I'm not getting any FRTs I have tried disabling the firewall on both node and server, I'm only having issues registering the node when I try using the devices.mdb. the devices.edb works but I get a slew of log files from that method.

[ArieHein]

This can always be a result of someone hardening the server by URLScan module and limiting verbs