View Blog

Why is this follow-up newsletter needed?

I want to thank you all for your comments and observations about my "Newsletter 15" rant. Some of you opted to post in my community forum, and there are some nice comments there. Others posted "side discussions" on, say, the SMS lists.

(PS: This whole newsletter update is being posted to the GPanswers.com newsletter folks and the SMS-list folks.)

I've spent the extra "quality time" getting to know the BDD a bit better. I'm ready to put this whole thing to bed, and I'm grateful for the insights everyone has brought to the table.

Again, if you have comments, my preferred way to handle them is via the Community forum. Or, if you're getting this on the SMS-list, then, feel free to post there too.

Special thanks to the BDD team (Michael Niehaus) for making contact to help me get to the bottom of some of my questions, as well as key members of the SMS-list (Rod Trent and Todd Hemsell) who chose to reach out to help everyone better understand why this is important to them.

Thanks, all.

PS: If you wish to respond, please do not email me about this topic. If you want to participate, please post herehttp://tinyurl.com/htaxw on my community forum.  

Findings

Ultimately, here are my findings after seriously going through the BDD materials. (Yes, true, I went thru them semi-seriously before. But this pass was even more so.)

Indeed, I found some videos of the whole process here and watched every single one and I suggest anyone interested in learning this better also watch them.

Warning: Whomever is giving the talk is clearly just READING from a script. And, hence, it's a little easy to "tune out" even though the information is quite good. With all that re-exploring, here is the Reader's Digest version on my findings:

About BDD/Standard

I seem to have been correct that the BDD, at the end of the day, deploys "Ghost-style monolithic images." These images are based on an "assisted scripted process" which helps wrap up all the steps (including hardware-specifics and timed reboots into the process.)

But in the words of the BDD team in a personal email: "In the end, this is captured as an image."

I think, in the end analysis, this is the big dealbreaker for me.

Let's say I change hardware. Or add something that requires another step.

Sure, I can go BACK and tweak my script to then create ANOTHER Ghost-style image. But that seems like more work to me. And now I've got different images running around.

Not that the BDD team or Microsoft needs my advice, but here it is: Take a hard-line stand, and support ONE method.

And that method should be a 100% automated, scripted install.

Here's why: People who already use Ghost-style tools already USE those tools without the process and guidance the BDD offers. And, the manufacturer of those Ghost-style tools should provide any process around them -- Microsoft shouldn't.

I don't think folks already using Ghost-style tools would necessarily jump ship over to BDD. I do think the BDD team could attract more flies by answering the problem of "How can I build a glorious, sexy scripted install that works on ALL my hardware, even if my hardware changes a lot?"

While it has a lot of excellent prescriptive guidance, I would be surprised to learn that many, many people use the BDD/Standard edition.

The BDD team has expressed that they do not assume AD is in place with the BDD/Standard edition. Therefore, none of the process involves any use of GPOs or scripts with GPOs. My suggestion to the BDD team: Start assuming people have AD and can "get it together" enough to use GPOs.

Seriously, even SBS installations run AD and most use GPOs, and they have 10-50 users.

If the target audience for the BDD doesn't even have ONE DC (hence, no AD) I think it's safe to assume that they DONT or WONT want to use a tool like this.

Do people WITHOUT AD really think "process" when doing anything? If the BDD's target audience really assumes about 500+ machines, then, c'mon -- we're ONLY talking AD here. :-)

About BDD/Enterprise

I think this is where the majority of administrators will find usefulness. The ZTI scripts which are part of the BDD really do add the "finishing touches" that SMS needed when the OSD was released.

And, I think that was my confusion, too. That is, that the OSD doesn't, by itself, come with the ZTI scripts. No no.. THOSE only come with BDD/Enterprise.

So, my overall suggestion would be to roll up the USEFUL BITS of BDD/Enterprise and marry them RIGHT to the OSD. I mean, is there a majority case in using ZTI without the OSD? If not, put the goodies where the SMS admins can just use 'em.

It seems, overall, that the SMS admins and I agree on the general "philosophy". That is SMS admins seem to often use BDD/Enterprise to smoke "broken" machines then use SMS to lay down their applications. That sounds awfully familiar when I teach about smoking a machine using RIS then laying down applications with GPOs. It's the exact same theory. (Yes, it’s true that GPOs require MSI packages, where SMS can deliver just about anything.)

There are some differences, and some similarities.

Difference #1.

With RIS, I need to walk out to the machine to kick it off -vs-With SMS, if the client is loaded and responding, I can kick it off remotely. If the SMS client isn't responding I need to either use RIS to boot WinPE or run out there with a WinPE CD-ROM. (Meanwhile, WinPE is still a "licensed" entity. RIS is included as a component for all Windows servers.)

Similarity #1

Both RIS and SMS/OSD seem to use the same "idea" of how they store files. That is, they're not “Ghost-style Monolithic images.” RIS stores "bunches of files" stored on the RIS server. SMS/OSD uses a "WIM" format. Both formats store about 20% less information than a "Ghost-style monolithic image."

So, at the end of the day, an SMS/OSD and a "naked" RIS install are going to take about the same amount of time. (That is, unless you're doing something tricky with the ZTI scripts and downloading a true Ghost-style image with your Ghost-style tool.)

My only question today is: If they're so SIMILAR in the underlying technology, why do we have two ways to skin the same cat? In the future, the BSD team tells me we won't. That's the right idea.

Advantage #1

SMS has always done a good job "staging" files in secondary sites. And, if you have a very large environment, say, with 25 branch offices, using RIS can be a challenge. This is because you'll likely want to load ONE RIS server and replicate it to all your branches. You would use Robocopy, XCOPY, DFS, or something else to copy that one RIS server to your 25 branches. But this route could be fraught with peril. (However, I would suggest that with the improvements with WS03/R2 this might be vastly improved.)

Onward and upwared

This isn't a BDD comment, specifically. But I think it's simply silly that that I must "run out" to a bare-metal machine with a WinPE disk, or have a RIS server available alongside my SMS just to boot WinPE to then get bare-metal installs up to speed. Unless I'm missing something, this is a kind of a big hole that the SMS team needs to address. I don't know enough about SMS 4.0 to know if this hole is plugged.

I like the idea that the ZTI scripts are "open" and customizable. And this, I think, is why SMS admins are "passionate" about the BDD in general. Again, however, my suggestion (for what it's worth) is to put the ZTI scripts right into the OSD if that's the people who use them.

Ultimately, the BDD has a nice message: Put some process around the way you do your deployments.

I can't rant about that. Clearly,

I'm not a huge fan of "Ghost-style monolithic images." I'd rather see you script the whole install, even if it takes longer. But the BDD's goal is to prescribe some repeatable guidence for those who choose to use Ghost-syle tools. Again, I can't argue with that -- if that's the way you're choosing to do your deployment. As I said in the original newsletter -- if you're happy with Ghost and their ilk, then keep on using it. The BDD helps you put some "process" around that deployment method if you choose to use it.

That's just good thinking all around.

However, in this "Son of rant" I've made some suggestions going forward I hope might be well received by both the BDD and SMS teams going forward.

One last piece of the puzzle: BDD will surely evolve in the Windows Vista timeframe. I would expect it to take on the new WIM/XIMAGE/IMAGEX formats Vista will support. But, that's another discussion for another day, isn't it?

PS: The BDD team responded in full to this content before it went live. And I've tried to inject the relevant feedback about the current state of the BDD and SMS/OSD back in before we went live. However, I'm currently seeking permission to print a full transcript of the conversation so you can read the response directly from the BDD team. In that response the BDD team discusses future directions, which are certainly interesting. When available, it will NOT be a newsletter. It will only be posted here http://tinyurl.com/htaxw on my community forum.

Subscribe, Unsubscribe, and Usage Information

If you've received this message as a forward from a friend, or are reading it online in the archives, you can sign up for your own newsletter subscription.

Also, if you want to unsubscribe, you can do that, too (but we'll be sad to see you go).

For all Subscription and Unsubscription information, we have a one-stop-shop page at the following address:https://www.gpanswers.com/newsletter

You can use this information as you see fit, but if you're going to copy any portion, please FORWARD THE ENTIRE email.

While Moskowitz, inc. tries to ensure that all information is technically accurate, we make no warranty with regard to the information within. Please use at your own risk. If you need personalized attention in any way, just email me: [email protected] If you have questions about ordering a book, contact my assistant Jon at: [email protected] We endeavor to respond to everyone who email