myITforum and Windows IT Pro Forums

 SCCM/WSUS Pain Points - survey results

Author Message

  • Total Posts : 502
  • Scores: 52
  • Reward points : 106080
  • Joined: 6/1/2002
  • Location:
  • Status: offline
SCCM/WSUS Pain Points - survey results Friday, May 28, 2010 11:09 AM (permalink)
Just wanted to drop this out here for posterity.  We had 2,654 participants.
1) What are your top pain points for the use of ConfigMgr and WSUS?
Integration  (30.50%)

Setup   (19.50%)

Use   (70.50%)

Documentation   (23.50%)

2) Based on your selection(s) above, why did you choose this?
  • I know the setup should be very simple, but once you go from a single site to child sites, very little instruction for best way to make it work. Also should have a simple cleanup method for outdated patches, but there is little to no doc on this either.
  • I have had many of my WSUS Admin sites uninstall for no reason.
  • Workstations that that do not complete installs, wmi issues, or patches that sit pending reboot.
  • FOr me it is the ongoing process. ok to get one deployment going, it is the "next" round - meaning -reusinging deployemnts ? tracking deployments. Separating workstation patches from Servers patches. Needs a best practice from start to finish.
  • FOr me it is the ongoing process. ok to get one deployment going, it is the "next" round - meaning -reusinging deployemnts ? tracking deployments. Separating workstation patches from Servers patches. Needs a best practice from start to finish.
  • Backup?? How do you backup and recovery ConfigMgr with WSUS? Need more 3rd party vendors Need better ways to deploy updates Better reporting
  • Not being able to deploy superseded/expired updates from Microsoft is a huge pain!! Since a specific set of updates goes through a 3-month lifecycle in our environment (test environment, pilot environment, then finally production), I have to download and manually package updates that are have become expired. This is EXTREMELY painful
  • next, next, finish, next, close.......
  • Is it possible to use a ConfigMgr SUP role as the WSUS server for a WUA that is not running the ConfigMgr client?
  • I love documentation. You can never have enough. Step by steps are my favorite.
  • Lack of flexibility in configuring restart options compared to straight WSUS with pretty popup and reminders.
  • Actually, all of the above..........this product leaves one hell of a lot to be desired. And I should know I have been a professional for close to 40 years now.
  • Having to contact a WSUS server for license terms causes major headaches for remote sites on smaller links where we can't justify the overhead of another WSUS session on the local server.
  • I've found it very difficult to add 3rd updates to SCCM and have them work correctly. SCUP seems overly burdensome considering I have to write my own installer scripts and package definitions. It would be really nice to see 3rd parties step up *cough* Adobe, Java, Google *cough* and supply some ready to go updates for their products. Also, I found the requirements for setting up WAN access to SCCM/WSUS using IPSEC extremely demanding and difficult. I would like to see another solution to providing updates via the cloud.
  • It is not very clear in the documentation or in the consoles whether you have configured it correctly and whether or not it is working properly. There also seems to be no way to automatically approve and deploy updates.
  • Because there's no auto-approval which is a basic function of WSUS
  • The design and setup of SCCM is a royal pain. The complexity, various updates, and many topology options are mind boggling. The product needs to be drastically simplified for easier designing and deployment.
  • The integration piece works okay but the use is terrible. The admin should just have to approve batches of updates pick a collection ans configmgr should do the rest. The workflow is just way confusing, and the documentation is terrible. I even downloaded the superflow and still confused. Just make it work like wsus but use SCCMs reporting, simpler for the admin, the point of this software is to make our lives easier.
  • Difficult to package applications. Needs a built in application packing utility.
  • For me it's frustrating having to go into the WSUS console to decline an update that I do not want to be scanned for in SCCM...and then having to wait a few days for the change to take place and the update to be expired (and removed) in SCCM. A close second is the time it takes for a home page synchronization to complete (the whole concept of a home page synchronization is something I'll never understand and a major thorne in SCCM's side).
  • All my clients finds it easier to use and understand WSUS standalone then the one managed by SCCM. I think that the way SCCM show things are a bit confusing. You have too many settings to configure. There should be a wizard based scenario for deployment (not 4 wizards) and more docs about how it should be done.
  • The whole procedure, is pretty **** horrible... Update list, Deployment Management and Deployment Packages. One of these needs to go. I have always thought it should be more like the advert process, where, you bundle say xp critical patches together and send it to a collection. Reporting is also pretty crap The no ability to set and forget for 'Approved' updates is very badly missed, after using WSUS. Though this is fix is v.Next or or V.Next or whatever they decide on.
  • Biggest issue is the way in which superceeded updates operate. Its rare that updates would get deployed as soon as they are released so often you are still mid testing/deployment when the next months arrive and any that get superceeded no longer deploy so you get estate inconsistency. The update scan should start at the latest and if thats not present scan for the previous, superceeded version, and work its way down the tree stopping when it finds installed that way you know your real exposure and it would prevent the superceeded deployment issue.
  • SCCM is made up of many parts instead of being one program.. Getting them all setup for Native mode is a very manual and difficult process that assumes you also have an expert in PKI to fill in the blanks of the documentation.
  • fault finding
  • There are still some settings that WSUS has that you can't really pull off with Config Manager - the primary one being install updates on Shutdown. It's great to be able to do the extra stuff like mainteance windows & deadlines, but it's not so great that you're essentailly missing something from the paid product that the free one gives you.
  • Manual daly usage. what is a good stratagie to get the max performens And how to handle updates
  • In WSUS I'm able to to auto approvals. If I first installed SCCM I searched for an auto approval option. And it took quit a while till I realised that there is no auto approval option.
  • still a lot of work to set up properly, and a lot of work to simply distribute a patch. should be ; select pactches, pilot, afterwards select audience and that's it.
  • In WSUS I'm able to to auto approvals. If I first installed SCCM I searched for an auto approval option. And it took quit a while till I realised that there is no auto approval option.
  • missing auto approval in SCCM
  • You have an unique console to administrate every task.
  • based on security
  • Much more weekly work than with WSUS alone.
  • For the ease of use with SCCM clients
  • 1. No way to filter your search by Architecture (exclude ia64) 2. Filters are inclusive only, So if for example if I wanted all classifications except drivers I have to select them all instead of just choosing to exclude drivers. 3. No way to exclude from seach based on if the update is a member of a list or not. 4. Seach folders are not customizable, for crying out loud all the data is in a SQL DB just add the option to create "custom SQL statements" for the search folder.
  • 1. No autoapprove of updates 2. Updates lists are disconnected with Deployments 3. No way to download update binaries in the branch locations from internet like it is possible in WSUS hierarchy, when you choose updates on the central server and bits are downloaded by subordinated WSUS servers from their own internet connections. Makes some troubles in global deployment scenarios and affects wan traffic to transfer bits between ConfigMgr sites in different parts of country or world. 4. Forefront story it not consistent. 5. No way to delete updates from the base,which are not needed anymore. For example administrator by mistate imported drivers updates. It flooded the ConfigMgr DB and there is no way to clean them 6.SCUP is able to import updates to WSUS and then to ConfigMgr and againt then it is impossible to remove the custom update from DB, even if it was just test update.
  • We need to WSUS to update deliver FCS definition updates, cause there's no way to do that in SCCM automatically. This means a lot of event errors related to WSUS Sync on SCCM. No easy to deleted unused updates.
  • We used to use WSUS stand-alone, since integrating it with SCCM I have to dig though reports to see which machines are non-compliant with each patch, where we were able just to double click before. Also, there is no facility to tidy the WSUS repository without resorting the the WSUS console. Finally, the products list on our installation has become desync'd, potentially meaning I now have to uninstall and re-install WSUS to resynchronise. Oh, and the product list isn't alphabetically sorted in SCCM.
  • Pure config mgr issue
  • I chose this because SCCM SUP can not sync with existing WSUS server which is in our organization. This is the biggest shortcoming for us.
  • Many smaller customers would like to be able to allow automatic approval for some computer groups in Software Updates in SCCM like in in WSUS.
  • We don't really have any pain points. I think the most important option for us is the continued use of a single WSUS instance with both CM and Forefront updates. In smaller companies, like ours (~300 computers), using WSUS like this is very nice. The CM client takes over the WSUS registry settings and basically configures all Windows Updates, including Forefront, to look at the same instance.... nice.
  • PXE seems to be unstable which leads to a lot of frustration.
  • It would be great to somehow enable the autoapprove functionality that WSUS had (if only they built the integration more around WSUS than SCCM) , and also to auto remove expired updates from packages. Also not knowing which Windows Updates options you can set via GPO, that will not interfere with the SCCM client.
  • kb articles were not always complete. I had to go to many sources and third party blogs when moving to SCCM 2007 with WSUS.
  • More difficult to use than the non-integrated WSUS console. There is more granularity with the SCCM console but there is definitely room for improvement.
  • The operations involved in maintaining Software Updates in ConfigMgr is the worst part. There is too many manual steps that could lead to human error in comparison of only WSUS.
  • Lack of any autoapproval. Difficult to teach others on how to use.
  • The handling of expired updates and how they impact secondary sites. Despite the urging that one should not touch the WSUS console when integrated with SCCM, MS Support urged me to periodically run the Server Cleanup Wizard to clear up an issue I was having with my secondary sites not fully synchronizing all my updates. Also SCUP integration needs some improvement. Removing / expiring updates is quite a process.
  • We are currently having an issue where some machines that have all patches are showing as non-compliant. For example, we have deployed XP SP3 to our machines and SP3 get properly installed, yet the compliance reports shows it as not being installed. I can find little documentation on how the compliance reports are generated and how to troubleshoot issues with them.
  • I always need to end up reinstalling the WSUS server as it keeps getting screwed up really crappy.....
  • Use and integration are the top pain points by far (and are related) The UI in WSUS is sub-optimal in many ways. There is no way to get rid of, for example, Itanium related updates and no way to group updates by architecture. There is also no supported way to force clients to install updates RIGHT NOW; they must wait until the scheduled time. This is particularly a problem with mobile/laptop clients who connect on a sporadic basis. The wuauclt/bits client software also seems prone to breakage. Several times per year I find my self having to manually reset the client software by hand via psexec when a machine, for some unknown reason, is no longer updating. Troubleshooting failing updates is also more difficult than it could be. On occasion, there is another bug where the machine will re-boot when a user chooses the "log off" option (on local console or RDP) when there is a pending reboot in wuauserv/wuauclt; this is unacceptable as it leads to unplanned downtime on servers. Workaround is to net stop wuauserv, then log out, then attach via psexec and net start wuauserv
  • Wsus interface is so easy to use, SCCM confuses this was more than it should. It would be nice to see a cut down version of the WSUS interface in SCCM.
  • DCM: creating baseline Configuration RS: making reports for management and view rights AI: true rich reports Devices that dont have SCCM installed and still managed by WSUS
  • I appreciate the control I have over update deployment to my live PCs, but in the operating system deployment process it's a hassle to either have to wait a very long time for "Install Software Updates" to run and it's also a hassle to create a pristine update package for each OS, 32 bit and 64 bit, in order to run "Install Software Updates Offline". I know we can also update our WIM offline and/or recapture an updated WIM on a cycle, but all of these are a pain. I guess it's part and parcel to keeping the OS updated in the first place.
  • I find the reporting function of SCCM to be very difficult to use. While it's good that there is a great deal of information available, it is so poorly organized that you find yourself getting lost in the details. Some MS updates have IDs that are over 65 characters long - who's going to parse through that? Compounded with this is the fact that creating custom queries or reports is neither well-documented nor intuitive. This leaves you either trying to stumble through the process or write something using SQL Reporting Services. But even that is not easily done since it's difficult to find a data map for the underlying SCCM database. In short, the canned reports are poor and creating your own is very difficult.
  • My comments relate to SCCM in particular. 1. Way too many steps to do simple tasks, like pushing software to a computer. Everything takes too long to do. 2. From the time I finish creating a collection and advertisement to the time the software begins to install takes too long. There isn't a way to push software out quickly in an emergency. 3. The documentation seldom answers my questions, especially regarding day to day administration, e.g., how to do something; what is the impact of checking or unchecking a box in the console. 4. When software or updates won't download, it's too hard to figure out why, and it happens too often. 4. Too many problems with software or updates not downloading, or not installing. Can't rely on it to do the job.
  • all in one
  • In a standalone WSUS you can automatically approve updates (Eg. critical and security), but this is not possible in the integrated Software Update Point. This means manual intervention in what should be a highly automated managed environment.
  • Thank goodness for Google.
  • For operators moving from WSUS to SCCM SUM the current usage of Update Lists is cumbersome. WSUS had a fire and forget approach, whereas creating and maintaining Update Lists is more time and resource demanding. To really get buy-in for SUM the management of Update List should be improved (automation through scripting, etc ...)
  • First of all - the system works perfectly, when it all comes to a SINGLE site or a ONE Primary PARENT and multiple secondary sites. However in a more complex infrastructure, the configuration and usage is totally painful and NOT DOCUMENTED. 1) when distributing the loads, it is not described in detail wether to install WSUS console only or the whole deal so that the scan info would be synced with with local WSUS not the ONLY WSUS server. (we decided to deploy full WSUS in every site) 2) The search folders are too limited - Unable to filter by architecture (x86, x64, IA64) 3) There is No built in option for automation to make a workflow so that the TESTING phase will be done for example automatically - awesome feature would be the option to create an automated deployment ( approving & deployment) like WSUS. 4) This is more of the SCCM related - the service window function is useless as it limits ALL the deployments - awesome feature would be a collection based service window that would not affect other deployments. All the issues listed are problems for me as a responsible for patch management service, but it could be that I'm just too dumb to use product :)
  • I would like to have similar auto approval rules in ConfigMgr/WSUS combination as the standlone WSUS has. Also I would appreciate path installation on shutdown like WSUS has.
  • Update logs are not very definitive at all. It is difficult to decipher what updates applied and when. On setup it was difficult for us to come up with a gpo to work in conjunction with sup to not have servers reboot.
  • SCCM does allow to use WSUS servers per site server, but in some cases you may want to have multiple WSUS servers per site. In certain situations the WSUS updates could be potentially large and will travel over WAN to branch offices where you have a DP available , but not necessarily a site server. We are also using Forefront which relies on WSUS , so we have additional traffic accross thew wire
  • There is still not a clean way to totally configure WSUS in SCCM. There are still times you have to go into WSUS to make configuration changes especially for auto-accept rules (Forefront). Also, WSUS does not always have all the same information on machines that SCCM does. It makes for a confusing time when doing updates or custom configurations.
  • Sccm makes a very smooth uncomplicated wsus setup very complicated and more time consuming. So much so that I have not integrated, and grin from ear to ear when another community member posts their latest battle story concerning patching through sccm.
  • Specifically remote control and corrupted WMI. Most complains we get about.
  • We find WSUS very rudimentary in its capabilities. Unfortunately we have had to resort to a 3rd-party product (EminentWare WSUS Extension Pack) to add much-needed functionality. It would be nice if we did not have to go to a 3rd-party to make WSUS truly useful. MS can do better than this..
  • Patch installation issues and troubleshooting
  • Integration does seem to work well, constant problems where SCCM complains WSUS is not configured, on the other hand WSUS logs say everything is perfect. Support for this product keeps on getting shuffled between the 2 different teams with each one blaming the other. Example being the mysterious problem of WSUS uninstalling itself when installed on a site server, how long did it take for a fix for this to be released?
  • It takes me a lot of time to set up a good patch deployment for servers. We use Test, Acceptation and Production servers which are all in different deployments. Alse we would like to have some machines to automatically get all available (MS) updates/patches.
  • 1. No way to throttle the initial download of WSUS metadata which means local Software Update Points are required in almost all sites and for no other reason. 2. Notification settings (tray icon) affect all machines in the site, Citrix servers then get tray icon which asks users to install patches which is not desirable or the tray icon must be turned off for all machines - collection/deployment based settings for this would solve a large amount of usability problems. 3. There is no option to install updates at shutdown through the start menu which is a feature of the standard Windows Update agent.
  • Ever created a BPMN Model for Update Management and tried to reflect that process with WSUS/SCCM? (By the way: Microsofts official shortname for "SCCM" is "Config Manager"). Microsoft Premier Support offers a Workshop performed by Operations Consultants called Software Update Management which at least allow to create the process but realizing the output with Config Manager and/or any other Deployment Tools is a pain without using Tools such as Service Center. Start merging your toolsets into one Management Console or integrate better process flow integration directly.
  • There is no way to target a schedule effectively from the second Tuesday (Patch Tuesday) of each month. Since there is no way to define something like 10 days from the second Tuesday, we must create a new deplolyment for each month for each group of systems receiving security updates. This costs us a lot of hours in each month that could be eliminated by having an effective scheduling system with ConfigMgr. Otherwise, we do not have any problems with ConfigMgr/WSUS.
  • Using SCCM to patch servers involves too many steps and does not have a good way to push just the patches my servers need to them when I want them deployed.
  • Documention is much more easy task to understand the setup
  • Not all updates are included in the catalog which means these updates either have to be deployed seprately/differently or a custom catalog (using SCUP) has to be created.
  • Can't get ConfigMgr to talk with WSUS. Errors are not saying anything.
  • Within SCCM the Software Updates / deployment management should be designed like software distribution where you can setup a patch approval package and then use advertisements with different schedules to deploy the patch approval package. Currently deployment management contains both the patch approvals and schedule/target collection so each time you want deploy with a different schedule or target collection you have to create a whole new approval list.
  • SCCM Is to complex to use. Example of problem areas are: - Way to many loggs to debug if you have problem - In need of many external MS applications that makes it more complex.(IIS, WDAV, DCOM, BITS ...)
  • The setup is not clear as it still reference some WSUS info but it says do not use WSUS...even the Microsoft Engineer who came 1 month on mission for us failed to make it work!!! The documentation about the roubleshooting is not clear as there are too many places to look at for a single process!!! It is suppose to be a Software Update ... but it is using Hardware Inventory as far for the Add/Remove Programs list... - Dominique
  • I run an offline WSUS Server and I have constant problems with it finding the updates I place on the WSUSContent Folder.. I follow the directions to the letter and constantly have updates missing...
  • The documentation for troubleshooting is poor in my opinion. Also, to my knowledge there are not any tools to troubleshoot/repair the client when something is broken.
  • Client issues are a maze of documentation - between the WSUS team and documentation what SCCM reports
  • We also rely on Forefront which uses WSUS natively. This has caused us some issues with deployment of occasional large virus definition updates. All of our clients are within boundaries of secondary sites. SCCM will assign secondary site as the active WSUS server, bu on occasion it may assign the Primary site which may be across a WAN. This is not that much an issue for SCCM Software Updates as the client may scan from the remote WSUS server bu itwill still get its update cntent from the local secondary site since it is within the site boundaries. But since Forefront uses WSUS natively, it will get its content diectly from the WSUS server (it does not know what a DP is). About once a month Forefront will "rebase" their definitions and release a large one. If a secondary site DP is unhealthy or fails a synchronization (which seems to happen on occasion), the clients may get assigned the WSUS server on the Primary site which may be across the WAN an they will start pulling very larged "re-based" virus definitions across the WAN. Even with alerting to try and resolve a WSUS issue, by the time someone is notified to take action, we are already impacting the network. Also, WSUS itself is a pain to manage in a large enterprise. We also get our share of bizarre Windows Update Agent errors from failed scans or deployments with no real guidance on what the errors are or how to correct them. Biggest headaches for us in order, WMI Health, WSUS, Windows Update Agent Health.
  • Automaticly approving some types of updates like forefront cliente updates. Having the updates check 4 times a day. Making the aprovel and distribution of new patches easier for non-sccm admins. I cannot always do it and have to delligate it.
  • They could not integrate even when the Microsoft Engineer cam on site to do it.
  • It appears to properly integration and setup WSUS and configmgr that I have to have PKI setup and working.
  • distribution of the updates is a pain. The first change i would make is to add the option to update distribution points when downloading updates. So i can do multiple downloads and not have to wait for ditmgr to update my dps's after every download
  • Clients, thats my pain point, we have actually termed a job decscription called SCCM client health.. I only had 2 machines with sms 03 I could not get the client installed on.. now I have 100s. What is it with this new client and WMI that it is such a pain in the rear.. I hate it. Microsoft cant fix it, and I have tried all the things on the net.. Its the only thing that makes me want to replace XP with Windows 7.
  • Not as smooth as other microsoft products where its a case of next, next, next, finish. This really does need polishing. Use - System Status - site status - warning triangeles but when you check for error messages none are listed. Wasting valuable time! Software updates - totally confusing when you first come to use it. Really needs rethinking. Can you hire someone from apple to design the user interface. Im really not happy with this feature as you can tell
  • From my experience with WSUS integration with ConfigMgr, I don't see why it needs to be made so complex. With WSUS you simply approve an update or set an auto-approval rule for a set of updates and that's all that needs to be done. With ConfigMgr, you need to create packages, advertisements and worry about which patches are in package A vs. what's in package B to make sure machines get the patches they need. Also, why do I still need to install the WSUS console if ConfigMgr is now managing updates? It seems a bit excessive and complicated.
  • Much more difficult to select and deploy updates in the SCCM Software Updates console vs. the WSUS console. Cannot visualize the update status for computers like you can in WSUS.
  • Being able to apply the updates in the OS build and capture process.
  • Used to the WSUS interface.
  • There are too many steps to configure monthly updates. I'd like to be able to automate this process further. I'd also like to be able to auto approve updates, like you are able to do withe WSUS.
  • Too much bugs in ConfigMgr. Weird performance of WSUS console.
  • Setup is particularly complicated. It would be beneficial to explore ways to streamline installation. For example, when installing on R2, it would be nice to have a script as part of the install that says "You have not met the following prerequisites: X, Y, Z. Would you like them configured automatically?" Since most features and roles are ready and waiting, this seems like a way the install process can be done more efficiently. I have two items in mind when it comes to Use. 1.) the reliability of the SCCM Client - client corruption, WMI corruption, etc. 2.) responsiveness of the MMC/SCCM console. - slow, prone to errors. Otherwise, I am very comfortable with SCCM as a whole.
  • For WSUS, is not really a pain, but it would be very interesting if I could delete updates directly from the console. I have kind of 19000 drivers updates that were never used. I know that they are not consuming any disk space, but the console and the reports are showing a lot of unnecessary information...
  • Update lists should be dynamic, when Microsoft re-release patches a day or two after they have been pushed out internally, we have to deploy the revised patches in a separate package. Ideally would like to update an update list, a deployment package and these changes are made down-level without the need to recreate the deployment to include the new entries in the updated update list.
  • The main pain point in the WSUS console is that it is not possible to copy text into the clipboard from the console's various panes; this makes it hard to document when testing & applying security updates. It is also not always obvious that an update has expired - it would be helpful if the status icons could reflect this information, and also if the reports could display information on whether an update has been superceded, declined or expired, as this information is currently only available on the console. Finally, the New Update email alerts do not distinguish between New, Revised and Expired updates, so it is still necessary to check the console to find out what has changed; it would be helpful if this information could be displayed in the email as well.
  • Use of WSUS under SCCM is far more complicated that the native WSUS MMC. Native WSUS patch approval is a matter of "click-n-approve." SCCM WSUS involves a lengthy series of steps that fails totally if even one step is not done properly.
  • NLB documentation is a bear to get through. Documentation should also recommend that WUA be sent via SWD in advance of any updates to WSUS itself so that clients don't yank the new agent unthrottled off the SUP.
  • You cannot deploy security patches once Microsoft Supersedes them. In a large corporate environment it is not possible to patch all machines on Patch Tuesday.
  • gui functionality regarding update list management is lacking(multi select,combine lists,...) making day to day management cumbersome
  • slowness of adding patches to the update list (even if you are not down loading the patch at that time).
  • This isn't a easy as it should be...
  • Find that when installing patches for workstations that it doesnt work as immediate as ITMU. Have to spend more time configuring the installs so that it will launch only when you want them to and not much later or before and then rebooting exactly when you need them to.
  • Setting SCCM to function properly between untrusted forests (without dropping Primary Sites everywhere) is a major pain point.
  • Updating existing deployment packages.
  • The proces of deploying updates to workstations is not the easiest way. The proces in the WSUS console itself is better.
  • When installing there is a distinct lack of clear detailed installation instructions and explanations.
  • Software deployments work differently than software distribution whereby I cannot set a flag to the deployment to re-apply updates if the initial package execution failed. Advertisements can be flaged to re-run if previous execution failed. Also, advertisements have expiration dates. Deployments do not. If that is the case, when can a deployment or package be deleted? In an enterprise deployment, not all laptops are online within a month period. Some laptops get online after 6 months or longer. Making the deployments and packages somewhat permanent. Use is a bit cumbersome to understand.
  • I would love to be able to install all the patches on the client via using a commandline. example wuauclt /inatallall or somthing like that!
  • When pulling reports from WSUS, the options for "Installed" and "Not Applicable" are combined. They should be separate.
  • Various client installation issues. It's always been scary to deal with them since I started using SMS 2003.
  • Integration and setup was super simple, documentation is available in a variety of sources but I still am not comfortable with the Use of CM to deploy updates. It just seems a bit cumbersome. I'm hoping that once I have used it more, I will be more confident of what the results will be. Right now, I just cross fingers and "hope" that the updates hit and reboots happen as planned.
  • clean up of expired/superceded (3 areas), consolidation into single production deployment after pilot/uat.
  • just trying to find 'the' document on how to use it.
  • Integration: If you have an existing WSUS its hard to modify it into the SCCM. Setup : Just build a new WSUS and set it up with SCCM Use: Not that hard to use, (there are some great tutorial sites out there on how to use it.) the problems come on the reporting side where it says some clients are not compliant or unknown, but when you look at the client its got the updates that were pushed to it. Documentation: In some ways there’s too much documentation its overwhelming, in other areas there’s too little.   
    3) If your pain point is not listed, please record your own...
  • Need to be able to auto approve patches like you can with WSUS. Need to have a report that shows what patches are on a specific box and when they were installed (date).
  • Need to be able to auto approve patches like you can with WSUS. Need to have a report that shows what patches are on a specific box and when they were installed (date).
  • Fix it or scrap it .... I know I wont be an advocate for it.
  • the problem is anytime to update distributionpoint, on many points we have problems is no update possible, this is wehn we added new patches to a established pakage. we dont want to generate every month a new package source for patches
  • Reporting. Could do with more out of box reports.
  • This is a conifg mgr point. Why is the app deployment process so long? Why isnt there a simple drag and drop? No create this and that, pick DPs etc? Can it not such this infor from sites and services? I am a contractor and Dublin City Council are thinking of dropping config mgr for the CA soln. The CA soln is much more expensive as well. Please simplify this process. Regards, James.
  • SCCM client related issues. Clients either stop working all together or inventories no longer work which result in having to rebuild WMI and a client reinstall. What an awful pain this is!
  • The whole process of publishing Non-Microsoft updates through SCUP!
  • Troubleshooting. Very little useful information is available. Troubleshooting is too complcated.
  • Delivering software to users through an advertisement upon request (unplanned) quickly. Also, setting up new, slow, remote connected site servers that server as distribution points and getting the necessary packages needed on that site transferred via mass storage device vs. the site-to-site copy process across the slow network.
  • Still missing a patch compliance report that can be targeted to aspecific collection to tell patches applicable vs installed as a percentage.
  • Its too unstable and it aimed at single installations. I manage lots of wsus installations. Unless I purchase a third party tool, I have to connect to each one to authorize the patches. On top of this I find each wsus installation gets screwed up by some patch or other maybe once year on each site. These servers only run ms software and an AV, so the only culprit to problems with the iis config, or acl changes can be windows update. I usually end up doing a reinstall... a total waste of time but its the fastest solution. Much of the problems are because the error reporting in wsus is close to non existent. You get an event 0x12345678, which has 100 possible causes, the cures are often the same regardless of the error. Why can't it report 'Access Denied error opening directory c:\windows\\etc....', or 'error xxx opening url http://srv/selfupdate' instead of the unhelpful cryptic messages it generates at the moment.
  • My worst pain is reporting. I have been using similar product from CA and there is a huge differens betwean CA's and MS tool when it comes to reporting. In SCCM do i need to make sure that it collects all the info i need, example Asset inteligence. I need to write SQL querys to get a report (no drag and drop with fields of inventoried info). I need to know what table to look in since the info is scattered around the tables.
  • All tasks for this process are fleaky as three Microsoft Engineer came on mission for us and only one make it works for a week!!! (: One layer on top of WSUS has created a lot of confusion on the WSUS Administrators what to do with SCCM... - Dominique
  • One pain point I have is trying to determine, when logged onto a server, what updates it thinks it needs vs what is available. The update <asdafakjweeeoru23987192834e7jkhvaf> just isn’t a substitute to me for kb987654. It would be sweet to have a tool maybe that I could point to a update log file on the SCCM client and have it build me a spreadsheet view of available vs needed and maybe trigger dates..
  • Clients.. Clients.. and Clients.. They just dont work as well as SMS 2003..
  • Regular problems with installation of upgrades on SCCM clients
  • SCUP - Dell and Adobe catalogs are the pits, I've had to educate Dell that they can't just remove entries without expiring them.
  • Can not distribute superseded patches
  • At the moment there is no option to 'synchronously' download and install updates via the Automatic Updates client under 2K/XP to make sure that all applied updates are installed, e.g. in a startup script. The 'wuauclt /detectnow' command does not wait for updates to be downloaded and installed before returning; this means that you either have to wait for the update installation time to kick in, or write a custom script using the WUA API (e.g. which is obviously not supported by Microsoft. It would be helpful if the wuauclt command could be updated to have an option to download and install immediately, rather than waiting for the timeout, to make it easier to support installing updates via Startup scripts, and to allow people using Windows Update to automatically install updates from the command line.
  • The pace of deployment is extremely slow. My security officer is forever on me because I approve the patches, sometimes even remotely run a "wuauclt /detectnow" and I still have to wait days and days for patches to be deployed. Only 6,000 users on one primary site controller, this shouldn't happen.
  • There is auto-approval of patch's, I would like to have auto approval rules for patches to go to test machines straight after patch Tuesday. Then after x days or hour, deploy to clients
  • The Reporting of the SUP is not good. Many reports must be created manualy what is very difficult. That needs to be changed.I am supporting this product so I expect a better solution from MS.
    <message edited by admin on Friday, May 28, 2010 11:10 AM>
      Online Bookmarks Sharing: Share/Bookmark

      Jump to:

      Current active users

      There are 0 members and 1 guests.

      Icon Legend and Permission

      • New Messages
      • No New Messages
      • Hot Topic w/ New Messages
      • Hot Topic w/o New Messages
      • Locked w/ New Messages
      • Locked w/o New Messages
      • Read Message
      • Post New Thread
      • Reply to message
      • Post New Poll
      • Submit Vote
      • Post reward post
      • Delete my own posts
      • Delete my own threads
      • Rate post

      2000-2017 ASPPlayground.NET Forum Version 3.9