Would it be an idea to temporarily dismount content databases before running the configuration wizard and mounting them again afterwards.
This means that without any content databases the configuration wizard will complete faster. Also, when remounting the databases again, the upgrade will run in parallel instead of sequential by running the config wizard.
Some important considerations are:
This has to be optional, for example by adding a parameter in which you specify all databases that have to be dismounted.
This only has to be done on one server. Also make sure you run this server first, for example using a WaitFor resource. Has to be done by the person creating the DSC config.
Questions:
Can the mount database run in parallel with the config wizard on another server? Will this even happen, if you have implemented using WaitFor?
Are content databases accessible during mount/attach/upgrade? This must be tested?
Problem description
(Idea provided by Markku Partanen)
Would it be an idea to temporarily dismount content databases before running the configuration wizard and mounting them again afterwards.
This means that without any content databases the configuration wizard will complete faster. Also, when remounting the databases again, the upgrade will run in parallel instead of sequential by running the config wizard.
Some important considerations are:
Verbose logs
DSC configuration
Suggested solution
Potentially add possibility to dismount content databases before upgrade, to speed up upgrade process.
SharePoint version and build
Operating system the target node is running
PowerShell version and build the target node is running
SharePointDsc version