The primary use case is to update the server and Windows desktop.
The deployment model we are using is on-premises, mainly.
The primary use case is to update the server and Windows desktop.
The deployment model we are using is on-premises, mainly.
WSUS doesn't have many features, so it's very difficult to answer this question.
This solution is easy to use.
Tagging in the server is complicated, and it's not easy to understand how to put it into a specific category. This solution is difficult for some people to understand.
The package validation process should be improved.
In the next release, I would like to see additional tools added to fix the engine issues on the client's side.
This solution is stable.
This solution is scalable.
We were able to deploy in multi-levels, now we have two levels.
I did not have to contact the technical support because this solution is easy to use.
We did not use any solution previously.
The initial setup and activation are straightforward, and the configuration tends to be quick with the validation of the package.
The deployment of this solution only took one day. It was quick.
I did not implement this solution through a vendor. I did it myself.
The WSUS cost is included in Microsoft Windows, and there are no licensing fees.
If you have many operating systems you would have to add more storage.
We did not evaluate other solutions.
I would suggest sharing packages between clients.
I am not using this solution extensively now because I am on the architect's side.
I am working as a freelancer and I use this solution with most of my clients.
I would rate this solution a seven out of ten.
The primary use case of this solution is to minimize the data flow from outside.
The interface is easy to use.
Many areas need improvement and many features don't work.
The clean up feature doesn't work. It's doesn't delete old updates that are not needed anymore.
The configuration process needs improvement, as it is not very good. The integration with Windows 10 was difficult, and a bit tricky.
The old backup files created by this solution use up a lot of storage, and this needs to be improved.
This solution would meet my needs if these issues would not occur every month.
We have between one hundred and one hundred and fifty users.
We have not used any technical support.
The initial setup was complex.
The deployment took three to four hours to complete.
The implementation of this solution was not done through any vendor, integrator, or consultant; I implemented it myself.
The pricing is ok. I don't have any issues with the pricing.
The integration is included in the Windows Server system, and there are no additional fees.
I am not satisfied with this solution. There are constant issues and most of the time it doesn't work.
I would rate this solution a four out of ten.
Our primary use for this solution is varied and broad. There is not a single solution that we use it for because it can take on different roles. It could be an exchange server, it could be the SQL server, it could be used for security and analytics, it could be used in cross-configuration, it could be used for domain name systems, it could be a file server — the potential of the solution leaves almost limitless possibilities. It truly has a million uses.
I don't really know what can be improved in the newest version of the product because they are about to release Windows Server 2019 and I am still working with version 2016, which is the previous versions of Windows Server. I'm not aware of the current improvements in the 2019 version first-hand so I don't know how to improve the newest release.
What I hope to see in the 2019 version of Windows Server is an improvement in how terminal services are implemented. This is one of the problems with the 2016 version. There are parts where functionality would be better if it wasn't based on PowerShell commands. I'm more of a GUI (graphic user interface) guy and I like the way a graphic interface can simplify using a product. I like to be able to see the GUI windows and graphic controls and I am less interested in using the command line because it is more complicated. There is no reason why the graphic interface is not better while also allowing access to the PowerShell.
One of the most interesting things that could be improved from the 2016 version would be having the ability to use SIC codes for call centers. They have some solutions for video chat and messenger, and other communications services. But when you need the work station's IP for the phone, you have to turn to the manufacturer for a solution. For example, with Panasonic, you end up purchasing the entire stack of server IPs to host the operation and operator. On-premises, it would have been nice if it was in Microsoft Server and not implemented through linked servers or messenger servers or other options. It would have been more convenient if it were just included.
One of the best things about this solution is the stability. The last time I turned off and re-started one of the servers was over eight months ago. That was eight months of uninterrupted, non-stop service. It's extremely stable.
I'm not much involved with scalability because I don't have reason to scale with our business model as it is at the moment.
We implemented the solution on-premises, which means that I own the exchange. We did the installation and the server is sitting next to a door right near me.
It is not really a matter of evaluating other options because I have used this one for twenty years. Nothing is perfect but this product is good or I would not have stayed using it for so long. So I base my usage on being familiar with the solution. I might change when I find a solution that is somehow better or if this solution does not meet our needs.
When I see the other open-source solutions — such as Linux and other options like FreeDSB or Unix — almost every one of them has an alternative solution to Microsoft Windows Server. That becomes a big problem for products that are not open-source because people don't need to spend money to get a good working product. If it comes freely, there really is no good reason to pay. The development of products that are not open-source begins to suffer in the market because the profitability is limited.
So that's a problem. Sometimes the non-open source solution would be chosen because the selection of the right product is dependent on the need and capability and not the cost. In other situations, the cost is more important and the choice will be for users to go to the open-source solutions because they are free.
The point is that choosing Microsoft Windows Server over other options is not a black-and-white proposition. There is a big gray area depending on the need.
Because Microsoft Windows Server is not open-source that makes it have limited application. In rating the product, because of that, I would rate this as only a five out of ten. This is not so much because the product is bad, but because there are so many other solutions that are essentially free that many companies can take advantage of.
We primarily use this for deploying and downloading through systems and servers.
It provides central management interface for deployment.
The most valuable feature is the integration of updates with our AD management. You can make an easy policy, embed WSUS, and in that actual policy we can embed to the extent to any device that generates gets automatic downloads from WSUS.
I would want the GUI on the continuing interface of the WSUS and more fine grain control. I don't want full blown enterprises. I want another object deployment, in a different kind of way that the enterprise just doesn't provide for me right now.
It is quite stable.
It is quite scalable. You can integrate it with your organization. It can be scalable to what you have set it to be.
I have not used tech support.
The initial setup was quite straightforward.
The ability to have more fine control within this solution is very important. It is not available for the solution in its current state.
