DSC EDB logs

Hi All,

I have a problem with the Devices.edb transactions logs.
I have noticed that C:\Program Files\WindowsPowerShell\DscService folder is around 60Gb in size. When I have checked I have found that all of this is edbXXXXX.log (edb7DB4D.log) files. I have around 500K of those logs.

Does any one know why this transactions logs are not committed, how to commit then and keep committed?

I have tried to compress this folder, but it looks like it was not supported. ESENT has failed to read the DB.

Also I have noticed that has broken PULL server as now none of the clients can download the modules that they were able to download before…

 Cannot find module xCertificate_2.0.0.0 from the server https://lbe-sh-mgmt-001.lbe.local/PSDSCPullServer.svc/Modules(ModuleName='xCertificate',ModuleVersion='')/ModuleContent. 
Could not install module dependencies needed by the configuration.
    + CategoryInfo          : ResourceUnavailable: (root/Microsoft/...gurationManager:String) [], CimException
    + FullyQualifiedErrorId : WebDownloadManagerModuleNotFound,Microsoft.PowerShell.DesiredStateConfiguration.Commands.GetDscModuleCommand

I have both modules and checksums. Tried to update the checksums, but all is useless.

Any suggestions?

Never seen this before. The Report Server is, unfortunately, a little bit of a black box. I’d obviously check the diagnostics logs to see if anything came up, and honestly might try deleting the EDB entirely to see if it’ll start over. Otherwise, you’re probably looking at generating a support ticket with Microsoft.

I have fixed the Modules distribution by generating a new GUID for the nodes authentication.

For the logs - still not clear.

How I can raise a support ticket to MS?


I’ve pinged some friends on the team to see if they have any suggestions, but that might take some time. Opening a ticket involves calling Product Support, and it’s something you’d need to pay for. If they determine that the problem is a bug, they refund that. You’d start by contacting Product Support in your region.

Known issue with the amount and sizes of the log files.
Was discussed on a post on this forum some time ago with one of the PS team pitching in.

Its also reported on the github repo and iirc also on uservoice.

Iirc its spoused to be fixed next release a.k.a. Win2016 server RTM or GA.

There is a service entry - made a while ago - that asks about this. It’s being investigated.

Is there a way to reduce the growth of these EDB####.log files on my pull server? I only have a small sample of servers using my pull server and it generates an excessive amount of files that I have to purge every day.

see https://powershell.org/forums/topic/dsc-edb-logs/

See https://powershell.org/forums/topic/dsc-edb-logs/. Merging.

Wow, not sure how I missed this post. My apologies.

For now, the workaround is to create a scheduled task that will delete the *.log files from C:\Program Files\WindowsPowerShell\DscService.

Hi Indhu,
And how then to deal with the EDB inconsistency?

“w3wp (17636) PSDSCPullSever: Error -1811 (0xfffff8ed) occurred while opening logfile C:\Program Files\WindowsPowerShell\DscService\edbFCC97.log.”


Restore from backup? :stuck_out_tongue:

These log files are the devil. I can’t wait until we get some utilities or the settings for these Transaction logs changes or something.

I only have a few nodes and I get about 1 GB of logs in a few days. ESE for the lose.

In the meantime: {gci ‘C:\Program Files\WindowsPowerShell\DscService*’ -filter “edb*.log” -exclude “edb.log” | ri}

*** Edit ***

Wait, maybe this?

gci 'C:\Program Files\WindowsPowerShell\DscService\*' -filter "edb*.log" -exclude "edb.log" | ?{$_.CreationTime -lt (gi 'C:\Program Files\WindowsPowerShell\DscService\edb.chk').CreationTime} | ri

“The checkpoint file, Edb.chk, is created by the Jet Database. Edb.chk stores the database checkpoint, so that it can replay logs starting with the generation containing the checkpoint, if needed. The Edb.chk file is a pointer in the log sequence that maintains the status between memory and the database file on disk. In the event of a failure, it indicates the point in the log file from which the information store needs to start the recovery. The Edb.chk file is essential for efficient recovery because if it didn’t exist, the information store must attempt recovery by starting from the beginning of the oldest log file it found on disk and has to check every page in every log file to determine whether it had already been written to the database. This process, of course, is very time consuming, especially if the only goal is to make the database consistent.”


I have found the answer for this:
ESENT cause not only this,but lots of other issues.

Current scenarios require edit of database path in web.config: C:\inetpub\wwwroot\PSDSCPullServer\web.config
find these two lines:

replace with:

It is also needed to copy Devices.mdb itself from the




Having the same problem. Disk on the PullServer is full.
Have also put written a script that deletes log files.

The best way to handle this currently I’ve found is to switch your Pull Server’s DB provider.
This will instead cause a single .mdb file to grow instead of the directory filling up with edb logs.

The only downside I’ve found with this, you will have to re-register all nodes to the server.

To do this:

  • 1. Update the dbprovider and dbconnectionstr lines in your web.config (if you don't know where you webconfig file is, it is in your pull server's document root, usually C:\inetpub\PSDSCPullServer): 2. Copy over fresh Devices.mdb from: C:\Windows\System32\WindowsPowerShell\v1.0\Modules\PSDesiredStateConfiguration\PullServer\Devices.mdb to C:\Program Files\WindowsPowerShell\DscService\Devices.mdb 3. Restart app pool(s) 4. Re-register all nodes
  • I found out how to do this from these links: https://github.com/PowerShell/xPSDesiredStateConfiguration/issues/201 http://stackoverflow.com/questions/24252635/powershell-dsc-pull-server-throws-internal-error-microsoft-isam-esent-interop

    I’ve already opened an issue at xPSDesiredStateConfiguration to be able to choose this at Pull Server creation, so here’s hoping they implement it soon.

    If anyone encountering this problem hasn’t voted on uservoice please do so. This item currently has only 10 votes but it seems like a lot more people are hitting it.

    Switch the DB provider, as Logs a not the only ESENT problem.

    Here is another way to solve the problem. Use Microsoft SQL Server for DSC :wink: