L U
My feedback
-
25 votes
An error occurred while saving the comment -
2 votes
An error occurred while saving the comment L U
commented
Bug...?
I have a problem with 'Available' application, that has a revision (not supersedence) updating - but the update is happening after I already uninstalled it. So it now becomes effectively a Required application. I can't uninstall and have it stay uninstalled.L U
supported this idea
·
An error occurred while saving the comment L U
commented
One more thing - the scope of removal/upgrade should never exceed the scope of the targeting collection, either user or device. I believe that is the bug that this issue was for:
https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/11532669-fix-supercedence-behavior
So if that issue really was fixed (?) then all we need now is to separate the deployment options for both the "Available" and the "Required" parts that are inplicit in an Available deployment of a superseding application where superseded installations exist in the targeted population (either user or device).An error occurred while saving the comment L U
commented
I vote for this - and also please increase votes available - the number of really good, even essential improvements is far greater than a paltry 10 votes.
At the minute, I could use 20 votes, and perhaps 40, given that we can tie up multiple (up to 3) on a single item.
An error occurred while saving the comment L U
commented
When superseding application is 'Available' these options are greyed out, but when we tick "Automatically upgrade any superseded versions of this application", then the User Experience activities to be performed outside the maintenance window, should be allowed: Software Installation and System Restart, And get back the option to prevent restart on a server.
By the way, the supersedence 'Uninstall' action runs as soon as the policy on the PC is updated, removing the old version, but the new version does not automatically install, it seems to be waiting (for that annoying maintenance window) even though it's not necessary to wait.
And some sites would not want the uninstall to go straight away, so the maintenanance window options should be made configurable, and apply to the removal of the previous version too, instead of what we have now: the removal running straight away, and the new install waiting till the evening.
BUG: I would classify the inconsistent behaviour above as a bug, which could be resolved by activating the configuration of the Maintenance Window options in the SCCM console, and tying both the old removal and the new install to those configured maintenance window options.
-
1,050 votesstarted ·
Admindjam
(Product Director, or Executive, Microsoft Endpoint Configuration Manager)
responded
Check out the new uninstall behavior in 1804 tp.
An error occurred while saving the comment L U
commented
We 'require' installation of an application with a deployment to a collection that shrinks as the machines upgrade old software to new.
And there is an additional 'available' deployment of the same application, to all machines, but the'uninstall' button stays greyed out (even after hardware scan, collection refresh, required deployment no longer applies because device has fallen out of scope).
Because the 'available' deployment remains, we don't want to uninstall, but we do now want to have the 'uninstall' button become active. This does not happen (CB 1910).
(later - ran app deployment evaluation cycle, and button changed to offer uninstall.)An error occurred while saving the comment L U
commented
Ah the good old AD software installation days.
But in SCCM, when an application is pushed to a user but installs in SYSTEM context, does it belong to the user or to the machine? If a corporate machine has a shared user history, we don't want a different user logging on to uninstall the software. We just want authorised users to be able to _run_ the software. We deal with this better with AppLocker and with App-V. We don't want a situation where software is installed, uninstalled, installed, uninstalled, installed ... as different people use the machine. We do, however, want to be able to pull all installations of the software when it is retired or superseded - even on machines where users are no longer using it and it would otherwise not be superseded by a user-pushed supersedent application.
If the targeting was to a device and the device falls out of scope in AD / out of the query collection, then we would likely want the software pulled off the device. (provided it was not due to an error in collection hierarchy where the members were temporarily dropped and re-instated - does happen in operation but not often).
-
1 vote
An error occurred while saving the comment L U
commented
There's definitely plenty of things App Deployment Tookit does that are harder in ConfigMgr, especially the breadth of user notification options.
And it saves a lot of powershell script debugging effort and mistakes.
(wish we had more votes, I vote for this)
-
1 vote0 comments · Ideas » Asset management, inventory, and collections · Flag idea as inappropriate… · Admin →L U
shared this idea
·
-
96 votes
An error occurred while saving the comment L U
commented
At least - make it a radio button for one click, not a tedious drop-down. And remember last choice across the session, and across sessions.
-
281 votes
An error occurred while saving the comment L U
commented
Using SCCM console across different domains/machines, profile not roaming anywhere.
So, also need easy export of settings so I can import them across all instances, and re-import after upgrades.
-
2 votesL U
supported this idea
·
An error occurred while saving the comment L U
commented
I agree - understanding that the deployment has both "Required" and "Available" parts means both need to be configurable differently.
Further details:
When superseding application is 'Available' these options are greyed out, but when we tick "Automatically upgrade any superseded versions of this application", then the User Experience activities to be performed outside the maintenance window, should be allowed: Software Installation and System Restart, And get back the option to prevent restart on a server.
By the way, the supersedence 'Uninstall' action runs as soon as the policy on the PC is updated, removing the old version, but the new version does not automatically install, it seems to be waiting (for that annoying maintenance window) even though it's not necessary to wait.
And some sites would not want the uninstall to go straight away, so the maintenanance window options should be made configurable, and apply to the removal of the previous version too, instead of what we have now: the removal running straight away, and the new install waiting till the evening.
BUG: I would classify the inconsistent behaviour above as a bug, which could be resolved by activating the configuration of the Maintenance Window options in the SCCM console, and tying both the old removal and the new install to those configured maintenance window options.
-
0 votes
An error occurred while saving the comment L U
commented
I've noticed that for superseded applications, maintenance windows for removal of the old version(s) is not honoured either (where the new application still waits for the maintenance window, the old version is removed as soon as the deployment is available)
I need my vote back for more urgent issues, but I hope this still gets a look-in.
L U
shared this idea
·
-
52 votes
An error occurred while saving the comment L U
commented
I vote for this (I've run out of votes).
We need for deployments with supersedence to recognise there are both "Available" and "Required" components to the deployment and allow complete, separate configuration of the user experience options for both.
-
50 votes
An error occurred while saving the comment L U
commented
This problem impacts on supersedence, which we don't trust to work if the 'previous' application version is not detected in the first place.
An error occurred while saving the comment L U
commented
My vote too. This looks like an omission (bug) from when user-targeted deployments were brought across from the Application Catalog to the new tiles interface in Software Center, but the guts are still missing so that the user still has to select the app and run it before an existing installation is detected.
-
62 votes
An error occurred while saving the comment L U
commented
I vote + 1 (have run out of votes)
-
258 votes
An error occurred while saving the comment L U
commented
With our organisation moving towards branchcache, the issue becomes not only about the installing PC's cache, but also about consuming space on adjacent PCs' caches (which already consume much of those small SSD's). But we also lose our DPs. Getting difficult.
An error occurred while saving the comment L U
commented
I have really tried - have application run a helper package to get its location (saved in a file) and use the source from there to install huge Application - but it turns out that WMI that has the programs is not accessible to SYSTEM account - so script fails to find the helper package. Lot of work to find out that the guts are just missing in SCCM client infrastructure.
https://social.technet.microsoft.com/Forums/en-US/97e65f89-b637-4e60-b1c7-c89b1144762a/cant-connect-to-rootccmclientsdkccmprogram-on-remote-computers-with-powershell?forum=ConfigMgrCBGeneral
:(An error occurred while saving the comment L U
commented
We don't want to have to expand the cache size on our clients' small SSDs just to allow one or two unreasonably large packages to download before they install - costly in many ways. We have to use the package/program model for these applications that would otherwise work fine in the application model.
We can't use a single common share because our network is so widely distributed - we rely on SCCM distribution points replication to get the software close to the clients that will install it, and not willing to stand up alternative replication infrastructure that would only compete with it over our WAN.
At least could you let us distribute content as a Package to DPs, and give us a simple, reliable way to dynamically find the correct _local_ distribution point package contents with a script run on each client (eg powershell and/or WMI api), until a full solution can be implemented?
Having Application model able to install from distribution point share - would hit the mark so much better.
-
0 votes
An error occurred while saving the comment L U
commented
To avoid needing to close and re-open the console, I can move the folder to another folder, then back again and it then shows the right order.
But it locks up the console for a minute or so each folder move, out then back in, while it re-organises its internal guts.
L U
shared this idea
·
-
4 votes
An error occurred while saving the comment L U
commented
others reporting the same problem:
https://www.systemcenterdudes.com/sccm-offline-servicing/ -
95 votesL U
supported this idea
·
-
51 votes
An error occurred while saving the comment L U
commented
Dependencies - issue with revisions - when I remove a dependency, the references in the depended-on application still shows the dependent application, but the link is to the last-1 revision. Disconcerting and unhelpful.
Turning off Application Revisions would take this problem away.
-
20 votesL U
supported this idea
·
-
2 votes
An error occurred while saving the comment L U
commented
Maybe this: if I create a sub-folder, I have to wait for the subfolder to appear in the GUI (takes 5-10 seconds, not inutitive), then select the folder before creating a new item. Now I understand, it's awkward. Needs a bit of work, for example, pre-selecting new folder so new items can be created in it without the extra step of manually selecting it.
-
25 votes
An error occurred while saving the comment L U
commented
The incredible slowness of the "Edit Membership" dialogue, I consider to be a BUG - just wanted to say that. As the existing operation effectively freezes up the user interface.
An error occurred while saving the comment L U
commented
Run out of votes, but the slow 'edit membership' is a real problem for us too because our update group space has many automatic deployment rules being created all the time.
These suggestions (Deppentöter and Newman) would save us a lot of wasted time.
Thanks!
Not sure what you are asking to change ... you describe something "as the behaviour is now" - can you clarify?