+1

That is an excellent idea, Keith.  Give each user their own MDT “workspace” and 
then copy their final work to the production share.

Mike



From: [email protected] [mailto:[email protected]] On 
Behalf Of Keith Garner (Hotmail)
Sent: Friday, September 2, 2016 1:39 PM
To: [email protected]
Subject: RE: [MDT-OSD] Multiple Users of Deployment Workbench

The list of “persistent shares” in the MDT Litetouch console is stored in the 
local user’s profile. So yes, if you login to a different account, then the 
list of shares in the console will be different, simply re-add them in to the 
console and that account will be good to go.

As for sharing… My recommendation is to create multiple Litetouch shares, 
perhaps breaking them down into production vs test. Additionally, if you have 
multiple users adding in content, then you can break down the test shares even 
further, perhaps:
                
\\server\deploymentshare_bob$<file://server/deploymentshare_bob$>
                
\\Server\deploymentshare_sue$<file://Server/deploymentshare_sue$>

You can easily open up multiple shares in the local MDT console and copy and 
paste objects between them. Bob and Sue can spend time adding 
applications/drivers/TaskSequences to their test shares, and then Mike can copy 
the components, when ready, to the master share.

-k

From: [email protected]<mailto:[email protected]> 
[mailto:[email protected]] On Behalf Of Marable, Mike
Sent: Friday, September 2, 2016 9:56 AM
To: [email protected]<mailto:[email protected]>
Subject: RE: [MDT-OSD] Multiple Users of Deployment Workbench

With Windows Server you get 2 simultaneous connections (2 RDP or 1 RDP + 1 
console).  Since you just had the one local account before you didn’t run into 
this.

Yes, you just need to “Open Deployment Share” in the MDT workbench to access 
your share.  From that point on it should appear in your MDT console.

No, you can have multiple accounts accessing the share and it won’t hurt 
anything.

If you’re making changes at the same time you could run into issues.  But 
nothing different than if you had multiple users attempting to modify the same 
file on the network.  I don’t know if MDT has the ability to lock an object 
when it is being modified.  Since it’s all simple XML files and not a database 
(like SCCM) I imagine that you can have multiple users modifying the same task 
sequence at the same time.  As long as your team communicates with each other 
then it shouldn’t be too much of an issue.

Mike


From: [email protected]<mailto:[email protected]> 
[mailto:[email protected]] On Behalf Of Wilcox, Kyle
Sent: Friday, September 2, 2016 11:07 AM
To: [email protected]<mailto:[email protected]>
Subject: [MDT-OSD] Multiple Users of Deployment Workbench

Hi All,

We just joined our MDT server to the domain for the first time today.  
Previously, we all just logged in with the same local account. That meant only 
one person could be working on it at one time. If I used RDP to access it, the 
other guy would get kicked out.

 Now that we are on the domain, I notice that I can be logged into the server 
with both the local account and my domain account at the same time.  Since my 
domain account is a new user, the deployment shares don't show up in the 
Deployment Workbench for me, but I assume I just need to click "Open Deployment 
Share" and it will let me select the existing ones.

Does it matter if multiple domain accounts access the same deployment share, 
but not simultaneously?

Does it matter if multiple domain accounts are logged in and making changes to 
the deployment workbench at the same time?

Would it be better to just have a domain account dedicated to managing MDT and 
avoid any issues?

--

Kyle Wilcox
Lead Technology Trainer for Westfield Washington Schools
(317) 804-1526

WWS Portal<http://portal.wws.k12.in.us/>
Create a Help Desk 
Ticket<http://helpdesk.wws.k12.in.us:8080/ehelpdesk/login.glml>
Technology Training Page<http://www.wws.k12.in.us/apps/pages/technologytraining>

**********************************************************
Electronic Mail is not secure, may not be read every day, and should not be 
used for urgent or sensitive issues
**********************************************************
Electronic Mail is not secure, may not be read every day, and should not be 
used for urgent or sensitive issues 

Reply via email to