xDscWebService: The IIS apppool account and credentials cannot be set

[tmeckel]

Details of the scenario you tried and the problem that is occurring

It is not possible to define the IIS Application Pool account. This is a problem if an SQL database to be used for the DSC Pull Server is not installed on the same computer. Then the application pool account must authenticate itself to the SQL Server database via the network. This is an issue for the "Local System" Account which is used as the account to run the IIS Application Pool.

Verbose logs showing the problem

N/A

Suggested solution to the issue

Adding a Credential parameter to the xDscWebService like with the xWebAppPool resource from xWebAdministration. (https://github.com/PowerShell/xWebAdministration#xwebapppool). Another option would be to allow to specify the application poolname to be used. In this scenario the deepolyment of xDscWebService can be combined with xWebAppPool so that at first the appool is created which is then referenced by its name in xDscWebService.

The DSC configuration that is used to reproduce the issue (as detailed as possible)

N/A

The operating system the target node is running

N/A

Version and build of PowerShell the target node is running

N/A

Version of the DSC module that was used ('dev' if using current dev branch)

ResourceType  : MSFT_xDSCWebService
Name          : xDSCWebService
FriendlyName  : xDSCWebService
Module        : xPSDesiredStateConfiguration
ModuleName    : xPSDesiredStateConfiguration
Version       : 8.4.0.0
Path          : C:\Program Files\WindowsPowerShell\Modules\xPSDesiredStateConfiguration\8.4.0.0\DSCResources\MSFT_xDSCWebService\MSFT_xDSCWebService.psm1
ParentPath    : C:\Program Files\WindowsPowerShell\Modules\xPSDesiredStateConfiguration\8.4.0.0\DSCResources\MSFT_xDSCWebService
ImplementedAs : PowerShell
CompanyName   : Microsoft Corporation

[stale]

This issue has been automatically marked as stale because it has not had activity from the community in the last 30 days. It will be closed if no further activity occurs within 10 days. If the issue is labelled with any of the work labels (e.g bug, enhancement, documentation, or tests) then the issue will not auto-close.

[stale]

This issue has been automatically closed because it is has not had activity from the community in the last 40 days.

[mhendric]

Reopening issue and making not stale.

[tmeckel]

@PlagueHO @mhendric I prepared a fix for this issue. When we agreed upon how to go on with PR #461, I can provide a PR for this here.

[stale]

This issue has been automatically marked as stale because it has not had activity from the community in the last 30 days. It will be closed if no further activity occurs within 10 days. If the issue is labelled with any of the work labels (e.g bug, enhancement, documentation, or tests) then the issue will not auto-close.

[tmeckel]

@mhendric @PlagueHO can someone set the in progress label for this issue here? I just imported the code changes into my fork (https://github.com/tmeckel/xPSDesiredStateConfiguration/tree/issue-463). I'll do some integration tests before I'll create a PR though. Secondly ... how can we prevent the bot from marking the issue as stale from now on?

[mhendric]

Done. And I agree on the stale bot; it's a bit aggressive. I'm not sure how to update it though. @PlagueHO or @johlju ?

[johlju]

See the stale.yml in the .github folder.

[johlju]

Btw. If the label is enhancement, bug, etc. (see stale.yml) it won’t be labeled stale.
It is important to label the issues as soon as the issue been determined that it should be worked on.