Yes, the Deployment Workbench as we know it is completely redundant for deployments created using SCCM 2007. How you deal with the points you raised, I will answer: 1. As follows: Customsettings.ini - you will have to edit this from within the "Settings" package source using notepad. Once your changes are made you will then need to update the Distribution Point. Bootstrap.ini - this is not a part of SCCM (ConfigMgr) deployments so you will not need to configure it. Unattend.xml - continue to use the System Installation Manager from the WAIK as usual. 2. Drivers - you should be creating a "Drivers Package" when you import the Task Sequence template from Microsoft Deployment Toolkit. 3. Patches - again, you should make use of the "Software Updates" functionality in SCCM for this. 4. DB Management - this is a grey area. If you rely on a separate database then you will have to manage this through SQL Management Studio, however, we only used to use a separate database to define things like the computer name and the packages that are installed according to the selected role. Our implementation has managed to completely do away with the need for a separate database by utilising most of the inbuilt functions of SCCM - for instance, Roles that define packages are now defined by collection membership. Our scripts enumerate every "Role Collection" that the computer object is a member of and installs the packages that are advertised to that collection. It's not as simple as that however we've made it work with some pretty extensive scripting. Overall, I do not see the need for the Deployment Workbench when you can do everything and more from ConfigMgr (SCCM). It was a little difficult to get used to at first but you eventually get the hang of it. Hope this goes some way to answering your questions. |