Author Posts

June 15, 2016 at 9:40 am

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='2.0.0.0')/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?

June 15, 2016 at 1:29 pm

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.

June 15, 2016 at 1:39 pm

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?

Thanks!

June 15, 2016 at 1:43 pm

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.

June 15, 2016 at 1:59 pm

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.

June 15, 2016 at 2:21 pm

There is a service entry – made a while ago – that asks about this. It's being investigated.
https://windowsserver.uservoice.com/forums/301869-powershell/suggestions/13399740-dsc-esent-database-management

June 17, 2016 at 6:50 pm

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.

June 19, 2016 at 1:55 am

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

June 21, 2016 at 7:58 pm

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

June 27, 2016 at 9:50 am

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."

Thanks!

June 29, 2016 at 5:36 am

Restore from backup? 😛

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."

https://technet.microsoft.com/en-us/library/cc961819.aspx?f=255&MSPPError=-2147217396

  • This reply was modified 2 years, 1 month ago by  Kyle Berger.

September 10, 2016 at 5:27 pm

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

$pshome/modules/psdesiredstateconfiguration/pullserver

to

$env:PROGRAMFILES\WindowsPowerShell\DscService\

September 26, 2016 at 1:03 pm

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

September 26, 2016 at 5:19 pm

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.

    • This reply was modified 1 year, 10 months ago by  JrdnRgrs.

    September 29, 2016 at 2:13 pm

    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.

    September 29, 2016 at 3:25 pm

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

    October 29, 2016 at 7:13 am

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

    Using SQL Server DB for DSC