February 26, 2016 at 9:36 am #35749
Has anyone had a chance to test DSC LCM configuration names after the WMF 5 RTM? I have setup scripts and LCM configs that have been working fine since the April release — but in testing yesterday I received the old error “The attempt to register Dsc Agent with AgentId “
In the pull server event log , the following error message –
Registration of Dsc Agent with AgentID = f8da017f-db3f-11e5-80ca-000c29c679f0 failed. The underlying error is : The 'Microsoft.Jet.OLEDB.4.0' provider is not registered on the local machine.
I've already checked the AppPool to make sure it supports 32bit applications. Not sure why this is happening.
February 26, 2016 at 11:18 am #35762
Can you confirm that Windows Internal Database is installed on the pull server? Which I didn't know used Jet, actually, but whatever I suppose.
February 26, 2016 at 11:22 am #35765
It isn't — however after installing the internal database, the same errors occurred. I don;t think it was needed in previous releases either — but it was a good idea worth trying!
February 26, 2016 at 11:26 am #35767
What's web.config look like? You'll need to post it as a Gist and paste the Gist URL here; XML won't render in the forums.
February 26, 2016 at 11:27 am #35768
February 26, 2016 at 11:31 am #35769
Here's the Web.Config form the Pull Server
February 26, 2016 at 11:41 am #35771
Does the server have a GUI? Can you run through the ODBC sources and see if Jet shows up?
Seems weird. As a test, I'm wondering if dropping the AD bits on there – but maybe not actually making it a DC – would solve it, since AD uses some of the same underlying database bits.
February 26, 2016 at 11:58 am #35773
It core — everything is beautiful core — But — you bring up a good point about the DC. I hadn't had problems in the past, but is worth a try. I've got plenty of empty core boxes, I'll try one of those.
February 26, 2016 at 1:15 pm #35777
Hey Don — your not going to believe this. So, I built a pull server on a clean core box, without also being a DC. Same error. Then I got creative:
I added the GUI desktop — guess what?
It now works. So Apparently, PowerShell DSC requires a Pull server on a GUI based server. I don;t know why – and I no longer care – I'm opening a hotdog stand. 😉
February 26, 2016 at 2:14 pm #35784
You need to float that on the NDA list. That shouldn't the case, and I know we've both built v4 pull servers on Core before. Maybe this is a dependency they missed or didn't layer correctly.
February 26, 2016 at 2:17 pm #35785
I have – Indhu has picked it up. All functionality of the Pull server does, and has worked, on core — It seems to be just this feature of configNames — like its a new bug. Anyway — will post back here what I learn form MS — and Will Anderson and I are still troubleshooting to see if we can find the dependency.
March 5, 2016 at 4:03 pm #36125
Is there any news about this issue ?
Jet4.0 isnt supported on Win2k12R2 but isnt marked as removed just deprecated.
And its quite obvious things that depend on it will fail.
You can see the difference in the MSTF_xDSCWebService.psm1 files between this version and past versions. In past versions Windows2k12R2 used the Devices.edb and the ESENT provider. Lower OS got the mdb.
March 7, 2016 at 9:59 am #36178
And as you can tell its not about PowerShell v5, its basically all oledb jet drivers on core server.
I thought about changing the psm file to enable the edb back for testing as the pswsiisendpoint.psm1 file used to create the endpoint still uses the Microsoft.isam.esent.interop, but I know its not the best way until its being addressed by MS.
March 7, 2016 at 10:03 am #36179
Yeah, and I'm not clear on why they switched to Jet for v5 to begin with. I half-suspect it's some desire to have Pull Server working on Nano, and that the Windows Internal Database has too many dependencies to make that happen, but Jet seemed-doable. We've kinda back-channel confirmed that Jet's a problem for Pull Server on Core, but it isn't the only problem.
I'd truly thought Jet was deprecated at this point, and MS wasn't supposed to be taking new internal dependencies on it. I mean, for pity's sake, I'd rather have some Sqlite or NoSql dependency than Jet. Or just a decent XML engine, even.
March 7, 2016 at 9:38 pm #36225
Jason – Thanks for your email in the NDA list. Pull Server is supported on Server Core – except on Windows 2008 R2. We are currently looking into this issue and I will report back on this thread
March 8, 2016 at 8:29 am #36274
Hey Nana! Unfortunately it doesn't work on 2012R2 and internally Indhu has recreated. I have a workaround (using the GUI) but very interested if there is another way as it does;t look good at the conference I'm at this week. Thanks for the help.
March 18, 2016 at 5:29 pm #36741
@Jason – there was a bug in the xDscWebService resource. It was setting up jet db which isn't supported on 2012 R2 (we use esent instead). The resource has been fixed. We will publish it on to the gallery. In the meanwhile you can grab the latest changes for the same from here https://github.com/PowerShell/xPSDesiredStateConfiguration (dev branch)
March 22, 2016 at 9:55 am #36879
Nana! Your Awesome! Thank you — I'll try this out and confirm. Thank you for the help! Cheers!
March 22, 2016 at 12:37 pm #36881
I rebuilt my pull server with WS 2012 R2 Server Core. I used version 126.96.36.199 of resource xPSDesiredStateConfiguration. I still get this error when I run Set-DscLocalConfigurationManager:
Registration of the Dsc Agent with the server https://test.dsc.contoso.com:8080/PSDSCPullServer.svc failed. The underlying error is: The attempt to register Dsc Agent with AgentId ... with the server https://test.dsc.contoso.com:8080/PSDSCPullServer.svc/Nodes(AgentId='...')
returned unexpected response code InternalServerError. .
+ CategoryInfo : InvalidResult: (root/Microsoft/...gurationManager:String) , CimException
+ FullyQualifiedErrorId : RegisterDscAgentUnsuccessful,Microsoft.PowerShell.DesiredStateConfiguration.Commands.RegisterDscAgentCommand
+ PSComputerName : mydschost
March 22, 2016 at 2:27 pm #36886
Hi Nana and Jim — I just tested with a few machines attempting to register to a Core based pull server and received the same error as Jim. I checked the web.config and its been corrected to use ESENT.
After testing a few nodes, I installed the GUI Desktop — and it worked. It registered the AgentID's just fine and pulled a configuration by config name. It seems that while the error message has changed from a Jet error to an unexpected error — there is still some underlying dependance that I just haven't figured out.
Nana, would you agree that this is still open?
March 29, 2016 at 2:32 pm #37067
@Jason – I will restart the thread on the NDA alias and I will have someone from our team work with you to dig through this issue and we can report back.
April 8, 2016 at 8:16 am #37433
This is currently being fixed — will report back to the group here shortly. If you are sporting, you might try the latest version of xPSDesiredStateConfiguration from the PSGallery. The Team has been very helpful and very aggressive with issues. Thank you PowerShell Team!!
Again, will put a final comment shortly for resolution. Cheers
April 8, 2016 at 9:40 am #37447
just deployed a brand spanking new 3.9.0 xPSDesiredStateCOnfiguration based Pull server ... and decided this is the perfect time to brush up on Pester. Ill see if this appears to work in core or not.
April 12, 2016 at 3:06 pm #37606
Using xPSDesiredStateConfiguration Version 188.8.131.52 or greater has resolved the issue.
You must be logged in to reply to this topic.