Click here to Skip to main content
15,662,532 members
Please Sign up or sign in to vote.
5.00/5 (1 vote)
I have written a program in VB.NET VS2010 that will submit mailbox extract requests to an Exchange 2010 environment. It presents a status list view that shows submitted, queued, in progress, complete, and erred mailboxes. All of the Powershell commands are submitted synchronously.

When you are dealing with 10 or 20 mailboxes the user interface is fine, but when you are submitting hundreds it becomes cumbersome.

I would like to break up the submissions into 20 mailbox chunks. My thought is to present up to 10 status forms that would contain no more than 20 mailboxes per form. Each form would be an individual thread that would submit then monitor the status of the mailbox extracts.

My question is should I create a single Powershell runspace into Exchange and pass it to each thread or is it better to create an individual runspace in each thread.

Any thoughts would be appreciated.

Your powershell runspace is probably not multithreaded so you can't have a shared one, so it is probably best if you create one per thread.
Any public static ( Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.

As a side not if you are using .net 4 use Tasks instead of threads.
Share this answer
A couple of things I learned.

You were correct in creating one per thread.

It is better to create a runspace for each and every time you need one rather than creating only one for the duration of the thread. There is a mild performance hit as creating the runspace is no speedy task.

As far as the Tasks go, being an old MAPI type, threadpools are evil. Since I use poling to monitor and maintain rather than interrupts , threads work just fine.

Share this answer

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900