/build/static/layout/Breadcrumb_cap_w.png

sms versus zenworks

Has anybody had experience with both specifically sms 2003 and zfd 3.x or greater? App deploy wise which is better? Why? Is SMS easy to deploy some changes like a single file, registry key, etc? Any other comments. I am not interested in other products and why they may be better

0 Comments   [ + ] Show comments

Answers (11)

Posted by: Bladerun 19 years ago
Green Belt
0
I've only used SMS, so I'll just answer questions about that. I've heard that SMS is the preferred tool, but I can't verify that.

SMS makes app deployment very easy, and its equally easy to make single file or registry changes as necessary. It also makes sorting machines into groups for deployment rediculously easy. SMS + Wise is my ideal setup. Can Zenworks deploy MSI as well as EXE? If not then stop considering it right now.

That being said, ONLY use SMS if your AD and DNS are maintain properly. At my last job we used SMS, but it was almost useless because DNS was so off. It saw many clients that were no longer there, and had difficulty seeing new machines.



I'm trying to talk my current employer into making the plunge into SMS. We do GPO deployment, and after the level of control I had in SMS I feel like my hands are tied.
Posted by: VikingLoki 19 years ago
Second Degree Brown Belt
0
I've used both, but Zenworks has been a while, back when 3.0 was first released. If you have an NDS structure in place, Zenworks is great. I think it integrated with NDS much better than SMS integrates with AD. (I've always considered AD a blatant rip-off of NDS)

Then again, who is using NDS these days? Since everything is now 1000% more likely to integrate with AD as opposed to NDS, AD is the better choice. By extension, SMS becomes the winner. Zenworks, while very good, had the rug pulled out from under it.

..IMHO
Posted by: plangton 19 years ago
Second Degree Blue Belt
0
I've used SMS 2.0 and Zenworks extensively, but can't comment on SMS 2003. If you have a solid NDS structure in place, there can be only one answer. Zenworks, it really is an amazing deployment and workstation management platform, and in my experience, far superior to SMS 2. Even without NDS, you can setup a DirXML based tree from your AD forest relatively easily (make sure you get someone experienced with DirXML if you are thinking about doing that though).

In response to VikingLoki, NDS is still widely used, though a lot of organisations have either migration plans to AD, or use DirXMl to create mirrored Directories to run Exchange/AD enabled applications.
Posted by: Thaiboxer 19 years ago
Orange Belt
0
I think they're both good. I worked with Zen for about 18 months in an environment where it had been implemented very intelligently - it was fantastic! I later worked with Zen for about 4 months in a poorly designed environment - it was a nightmare!

Same story with SMS. I've worked with 2003 and it's great, but the administration was a little harder. If you implement it well, SMS is a wonderful tool.

Either product can be great or terrible, I think a lot falls to how well it's implemented. My preference is SMS 2003, but only because I'm more comfortable with it.
Posted by: VikingLoki 19 years ago
Second Degree Brown Belt
0
In response to VikingLoki, NDS is still widely used,

Got a good laugh on that one. My initial reaction was "What world is this guy living in?"... Then I saw "From: Sydney, Austrailia". Oh! That world! [:)] ('ello mate!)

I suppose that's quite possible on a global scale. Personally, I definitely prefer NDS and ZEN but here in the states you end up being a bit "other worldly". Almost every vendor we deal with integrates with AD, but not NDS. I'm also completely unfamiliar with linking NDS with AD. No clue how smooth that would be.
Posted by: kkaminsk 19 years ago
9th Degree Black Belt
0
No matter what you use the implementation will make the difference. Working with SMS 2003 and ADS has been my preference because of how feature rich the environment is (custom MOFs, full WMI inventory, SUS and Web reporting). Zenworks is better at making application deployment features visable to the administrator but when it comes to auditing the desktop environment I find SMS is more feature rich.

Still it comes down to the infrastructure. If you have have a full blown NDS then you should be using Zenworks. If you have a full ADS you should consider SMS even if you are running NDS and ADS side by side.
Posted by: plangton 19 years ago
Second Degree Blue Belt
0
Hi VikingLoki,

Heheh we depends on your definition of "widely" - certainly I've worked for a global telco that used NDS (not based in Aus), various governments, a global airline (that is based in Aus), and know people who work in exclusively NDS directory based fields for a mix of local/multinational companies. Thats not to say its in the majority, its just that a lot of companies invested a lot in setting up their NDS infrastructure when there was little to no alternative, and now face moving to AD or creating alternative mirror basd directories.

You'll find a lot of products won't say they link with NDS, but will link with LDAP - NDS is LDAP compliant (as is AD) and I've used a few LDAP products with NDS with no problems at all.

Linking NDS with AD and vica versa (via a utility like Novells DirXML) CAN be smooth, when implemented properly. Like anything else I guess :)

But I'm getting OT just for something different...
Posted by: jyuschak 19 years ago
Yellow Belt
0
Hmmm, well, I have worked with both considerably, and continue to do so today. The best thing I can say is, if you are in a small environment company, I'd look to SMS 2003, if it's a large Corp environment, then hands down Zen, but when I say Zen I mean a combo of Zen for Desktops and Zen for servers. With the Newer 6.5 you can even distribute from Zen into an ad environment.

I like SMS's reporting features a little better, but application and distribution wise as well as how well the servers handle the load, and how many servers you truely need to support an environment are why I say Zen for Large corp enviornment.

When I say large, we have approx 175,000 desktops in our environment, and run Edirectory (formerly NDS) alongside AD. AD is still (sorry to say) much much less efficient of a directory. Though it has been making strides.

So take it for what it's worth, they both have their places... I like both, but they are meant for different situations... To me it's like comparing apples to oranges... well almost.
Posted by: kkaminsk 19 years ago
9th Degree Black Belt
0
That is an excellent point to bring up. Most of the ZEN environments I have worked in have been quite small. The largest SMS implementation I supported was about 21,000 clients and SMS had some issues especially with consolidating the inventory data into one database. The solution was to buy a massive 8 way database server but even that still did not resolve some of the issues. What drove me mad is every time we complained to our TAM(s) they would always bark back at how Boeing was running 300,000 clients. But that never solved our issues.
Posted by: Bladerun 19 years ago
Green Belt
0
175,000 GOOD LORD.

Ok yes, I should clarify then that I used SMS in a very small environment (4000 clients).

Wow, managing 4000 clients with 400 apps was painful at best. I can't even begin to fathom 175k.
Posted by: jyuschak 19 years ago
Yellow Belt
0
approx 7,000 applications here. :-) We have no teeth anymore to tell the clients no... they want something upper managment says give it to them... Arrgggggg!!!
He he

BTW, for you SMS users, if you haven't already you should check out SP1 and the OSD feature pack... It's pretty cool!
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ