Are there any thoughts on perhaps increasing the number of threads that are used to run esutil for exchange verification?
Thanks for the suggestions, I will be sure to pass these along.
As an aside, there have been improvements to NPM in the latest Nimble Windows Toolkit. If you are running 1.4.7 on your array and NWT 126.96.36.199 on the specific host you should notice some changes.
Could you provide some more detail on your situation?
Are you talking about running this as a stand-alone verification, or when verify is triggered as part of a Nimble NPM Snapshot?
And what is the outcome you are trying to achieve by increasing the thread-count? I have my guess of course ;-)
This is something that has been on my mind for a while as well. I'm not for sure, but I think based on how he described Exchange Verification John is speaking towards Nimble NPM snapshots.
I have noticed in our environment that when NPM takes a snapshot and then connects that snapshot back to the Exchange Server to run esutil it only connects on one iSCSI connection even though the original iSCSI connections is setup to use 2 using MPIO. This creates a bottleneck reducing potential bandwidth in half and slowing down the verification process. Would be great to have both iSCSI paths enabled when the snapshot is connected.
If that is too difficult then maybe a solution would be to use more of a Targt Group concept I have seen around the iSCSI world where 2 volumes/drives could be passed through the same connection. This Target Group concept seems like it could offer the most flexible option with the least amount of development/support as snapshots would just follow the same path as the original connection no matter how it is configured.
Sorry it took so long to respond. My question was in regards to when verify is triggered during the nimble snapshot.
Retrieving data ...