Microsoft System Center Suite is a family of IT management software for network monitoring, updating and patching, endpoint protection with anti-malware, data protection and backup, ITIL- structured IT service management, remote administration and more.
It is available in two editions: standard and datacenter. Datacenter provides unlimited virtualization for high density private clouds, while standard is for lightly or non-virtualized private cloud workloads.
$1,323
Progress Chef
Score 6.5 out of 10
N/A
Chef IT infrastructure automation suites were developed by Chef Software in Seattle and acquired by Progress Software in September 2020. The Chef Enterprise Automation Stack is an integrated suite of automation technologies presented as a solution for delivering change quickly, repeatedly, and securely over every application's lifecycle. The Chef Effortless Infrastructure Suit is an integrated suite of automation technologies to codify infrastructure, security, and compliance, as well as…
N/A
Pricing
Microsoft System Center
Progress Chef
Editions & Modules
Standard Edition
$1323
Datacenter Edition
$3607
No answers on this topic
Offerings
Pricing Offerings
Microsoft System Center
Progress Chef
Free Trial
No
No
Free/Freemium Version
No
No
Premium Consulting/Integration Services
No
No
Entry-level Setup Fee
No setup fee
No setup fee
Additional Details
—
—
More Pricing Information
Community Pulse
Microsoft System Center
Progress Chef
Considered Both Products
Microsoft System Center
Verified User
Anonymous
Chose Microsoft System Center
None. We are a Microsoft business, and this is THE tool for imaging, packaging, remote support, and antivirus management. Microsoft's tool is the best for managing its software, systems, and antivirus clients. I will say that Microsoft Intune, the cloud platform, can be used …
The versatility of the suite of application provided by the Microsoft experience center was way above the other competitors , it helped gained leverage over the other products in the market . That why we made the decision of choosing Microsoft system center as a infrastructure …
We use Azure, we have lisences, so we have no needs any other cost. And also, we want to save backup data in Azure. Veritas ask additional cost reagurally and have to rebuild bakcup environment.
Because Datadog was too small, we decided quickly to use Microsoft System Center. We use a lot of other Microsoft products so that discussion was quickly set internally.
We have used Ghost from Symantec (licensed), FOG and Clonezilla which are freeware products. All three products had their pros and cons. The two freeware products were functional but did lack some polish, and Ghost was a good product for imaging of desktop computers. All did …
We previously used a mix of FOG and Clonezilla to image machines. The biggest issues with these products is that changing one piece of the image required you to rebuild the entire image itself. These pieces of software also did not allow you to manage applications and Windows …
We are using Microsoft products for a long time, so the overall confidence played a part in the decision, the feature set and licensing cost was also very high when compared with above products, so we decided to use System Center for our environment, so far it has solved many …
Microsoft System Center has more options. Microsoft System Center has the ability to image PCs as well as remotely connect to PCs, and software installation and patching where Symantec Ghost Solution Suite didn't handle all of these options as well. We haven't looked at many …
Much better UI for system center. Also, Tivoli was discontinued, so it was an easy decision. Altiris was acquired by Symantec but was unreliable and painful. It's UI was unresponsive and generally outdated. It wouldn't clean up old packages and would hog GB of disk space, …
I would say Microsoft System Center and Oracle were about the same. Oracle seemed to be a little more user-friendly, but for the most part, they are both comparable.
I have used ZENworks, Altiris, and Landesk. They are all good products in their own right and have many strengths. The pricing, bundling SCCM with our Microsoft site license, really helps create an ROI that puts SCCM over the top. Pricing aside it is a tool designed by …
I have not chosen this software directly because I found myself in an environment that already used this product, a purely Microsoft environment. Therefore the choice that has been made has proved very effective and above all suited to our needs, and for this reason, no …
It's better than others because Microsoft knows its own OS better than anyone. It has a very rich feature set and allows companies to hit many areas of need with one tool. You can have IT staff get multiple tasks done just by logging in and they don't even have to leave their …
We built our POC of the private cloud with vRealize Suite and Microsoft System Center. We are VMware shop so we thought the vrealize will be solution for us but we found pretty fast the vrealize suite is very limited and very expensive compare to Microsoft. With System Center …
Chef is the more developer-oriented of the three main tools in this space. It has a steeper learning curve as a result but it allows you to do more. Puppet seems to be more geared towards automated the management of the operating system. Ansible is an excellent tool but …
We considered the three leading competitors in the field: Chef, Puppet and Ansible. Ansible is a very strong competitor and has a nice degree of flexibility in that it does not require a client install. Instead the configuration is delivered by SSH which is very simple. Puppet …
Puppet Labs and CFEngine are also open source and competes with Chef. Chef has more support from the community with templates available for large scale IT deployments. RedHat Ansible is better suited when you are already using RedHat OS and OpenShift since it comes as it comes …
Briefly looked into Puppet but ended up going with Chef because a colleague had experience with it instead. Didn't get far enough into a deployment to even really compare the two.
Vice President, Chief Architect, Development Manager and Software Engineer
Chose Progress Chef
We found that Chef was easy to use, and we liked the whole concept of recipes and cookbooks. We were using the concept of recipes and cookbooks for our SQL development, so Chef was a natural fit for our team members and environment. That whole paradigm is easy for everyone …
I've mostly explained the differences between Ansible and Chef in my previous answers. I generally prefer Chef over Ansible because the platforms we use have very convenient cookbooks.
Chef is easy to install and manage, and the learning curve is minimal, as most of the engineers are already aware of the syntax to configure services. With flexible crating recipes and cookbooks, Chef made our jobs easier, and also it integrates well with Puppet. Overall …
Chef is something we have been using for a while, so it is the natural choice when training new engineers to maintain our systems. If I was to choose a configuration management tool now, I would pick Ansible mainly because of its agentless nature and YAML cookbook language …
To be honest I believe SaltStack would provide a very similar experience to Chef and would allow us to automate much of our operational tasks in the same way, however I feel that Chef is more conducive to a mixed environment of Windows and Linux servers. This is the primary …
We believe Chef is a great tool for DevOp. It works really well with repository tools such as bitbucket and artifactory. The other products we evaluated either were too pricey or did not have the support we needed for a company that was very vanilla with automation. We selected …
We were evaluating Ansible as it was agent less, SSH based, simple to use and is completely based on SSH protocol. As and when the servers count increase the performance might degrade. One main disadvantage with Ansible is it is more suitable for linux based systems where SSH …
I really found that Chef to be much friendlier and innovative than Puppet. There is an opinion in the DevOps community that says that Chef is friendlier to programmers whereas Puppet is friendlier to system administrators. This might be true, as I do come from development …
Chef is good for organizations with many servers, because of the client-server approach. I guess ansible can be used for some 20-40 servers, just ssh and run the playbook. Chef is in ruby which is a really simple to learn language as opposed to competitiors.
Chef was easier to setup than Puppet. It also has better Windows support and documentation. Reading through the Chef documentation gave good examples on how to configure things for Windows environments, however Puppet was a bit lacking in that regard. Puppet has better support …
Ansible and salt stack seem to be the new cool kids on the block because they are easier to setup and manage across smaller teams. I think the use of puppet is dying down in favor for these new technologies. I would like to see chef use cases with simpler implementation.
We used a product before that was designed to prevent users making changes and saving files to the desktop computer. This required a renewal of the license. By using SCCM in our environment we were able to discontinue using that product because SCCM allows us to completely restore a machine back to the original configuration. We have taught our users to save their individual work on either a network drive or a cloud drive. By doing this, if we do a re-image of their machine they have lost no data, and it makes for a faster resolution. In some instances having a computer in our SCCM environment it can become cumbersome when creating new users for very specific purposes. It can be done by creating new organizational units and applying new policies but when in a pinch it can be frustrating. For the most part we have tried to make "new" purpose images and groups to at least accommodate a quick install.
Chef is a very nice tool for establishing and maintaining a consistent configuration across a range of servers. In addition, Automate allows the continued monitoring and maintenance of servers so they don't drift from established standards. Overall, it deals very well with complex systems. Chef is slightly less applicable for a micro-services approach where the servers are replicated from a simple and known starting point.
Provides our users the ability to deploy and manage our own datacenter based on defined software with understandable solutions for storage, compute, networking and security.
We are able to update at once all the computers from all departments without having to install the OS on every computer.
It allows us to have everything in one place for database management and datacenter inspection as well.
Chef is very easy to learn. Written in ruby, Chef code is high enough level for non-ruby coders to get a general idea of what the script is doing.
Chef can be a one stop shop for writing code, testing infrastructure, and deployment of applications.
The Chef support team is very helpful in their auto manager support as well as active support in their Slack channels from development engineers & architects.
Needs web based storefront for requesting new software
Needs ability to manage the packaging work flow better
Sometimes is slow to download and there is no indication the entire catalog is being loaded, resulting in confused users not being able to find common software in the available list.
One main concern with Chef is the maintainability of Chef master.
The Chef-client should be installed on every node we want to do any automation.
It is mostly Ruby and there's a learning curve. Need to understand the fundamentals of Chef very throughly to play around with attributes, templates etc etc.
The Chef-client agent needs to be run on the nodes frequently to update the details of it state to master. And also to index the nodes based on tags.
No matter our issues with the software, its ability to centrally manage systems, patch, image, and remote help users has far exceeded our timeliness to help staff. Its ability to keep current, enable us to keep the network secure, and standardize our end-user experience has saved us many hours, dollars, and time every day.
The suite of tools is very powerful. The ability to create custom modules allows for unlimited potential for managing all aspects of a system. However, there is pretty significant learning curve with the toolset. It currently takes approx 3-4 months for new engineers to feel comfortable with our implementation
It loads quick enough for basically all our systems. Because we have this for local dev environments, speed isn't really a big issue here. Yes, depending on the system, sometimes it does take a relatively long time, but it's not an issue for me. One thing that is annoying is that if I want to make a small change to a cookbook and re-run the Chef client, I can't just make the change in the cache and run it. I have to do the whole process of updating the server.
If I had to dislike something about the system it would be how much it changes once you upgrade. This could be more of a problem of mine since I get used to one way and don't like it when it changes so much. I am enjoying the newest update, but it is a mess when you are actually going through the upgrades.
Support for Chef is easily available for fee or through the open source community as most the issues you will face will have been addressed through the Chef developer community forums. The documentation for Chef is moderate to great and easily readable.
None. We are a Microsoft business, and this is THE tool for imaging, packaging, remote support, and antivirus management. Microsoft's tool is the best for managing its software, systems, and antivirus clients. I will say that Microsoft Intune, the cloud platform, can be used for those with heavy 365 usage, but for us, that does not meet our current company needs.
Chef is the more developer-oriented of the three main tools in this space. It has a steeper learning curve as a result but it allows you to do more. Puppet seems to be more geared towards automated the management of the operating system. Ansible is an excellent tool but requires you to allow SSH connectivity into all of your instances.
We have been able to automate our patch management, firmware and other security concerns.
We have a standardized "image" ensuring our setup is consistent across the enterprise. This alone has saved us in time to support and time to understand how to use our desktops.