Have to say, I agree with this one, but I think the exe component may be out of reach for the config Mgr team alone especially in the short term. The script installer should look for scripts (.bat,.vbs,.ps1 at a minimum) though, that has always annoyed me.
I think the biggest issue with the exe option is that there is no standard for exe files.
I always thought that MSI stood for Microsoft Installer, but it is rare to find anything supplied by Microsoft these days in the MSI format, so if Microsoft rarely use MSI's, why would anyone else.
As Microsoft have moved to exe installers for the majority of their software, maybe something needs to be organised between the CM dev team and the rest of Microsoft to find a way to standardize and make Microsoft exe installers easily deployable from CM or standardize on a format that is more easily deployed from CM.
Maybe you can lead the charge to standardizing exe installers for Microsoft products in a way that you can work with in CM. (if MS standardize, maybe others will follow...). If you then add support for exe's in the wizard, would there be a way for it to only see the supported type exe's
I realize there are many different formats for exe's and a lot of them are wrappers with various installers inside, including MSI's, but maybe a meeting internally to decide on some standards might be the first step. We can only hope.
Note that on this page, there is a list of the issues with exe's, maybe you can use that in your meeting agenda with other department heads for standardization of exe installers :) - https://serverfault.com/questions/11670/the-corporate-benefits-of-using-msi-files/274609#274609
agree with this one, SCCM support of exe's (main offenders for premature detection) needs more work with the main issue being detection methods for exe wrappers. Standard exe's we routinely repack to msi to simplify deployment, but when they are wrappers extracting and running other installers, the detection method is nearly always problematic with detection happening before the installations have run. As the majority of installers released by Microsoft in general are exe's of one form or another rather than msi, shouldn't exe deployment be config mgr's priority?
I've spent the last two days trying to figure out why they weren't publishing automatically, so happy I found this page and can move on to doing the ADR updates publishing manually. I am about 25% through a migration of desktops to W10, so I guess, I just need to put it in my calendar to go back in and publish any newly identified drivers so the ADR can pick them up. Then we'll need it as part of our process for every new model we implement to identify and publish the updates manually so they are included in the ADR. Next time I get a vote back, I'll be adding here for sure.
maybe autopublish any that have a "Required" tag...
I agree with this - update dependancies for all applications to new version of application.
If I had votes left, I would also vote for this. When you think of "dependancies" this doesn't just mean all the C++, dotnets etc. Often applications supplied by vendors have multiple installers required with one main app and multiple smaller required installs that make the main app function. you should be able to mark dependancies in some way that indicates they should be uninstalled if you run the uninstall on the main application.
I believe my thoughts are along the same lines as this request, so I'll add my vote here.
In the Query statements, In Criterion Properties, the value button
1. don't truncate by default, make the manual registry key the setting to truncate if you for some reason want to. Currently, you need to add a registry key manually to allow you to see the entire list of values or it truncates at 2000 items. Alternately, just have a button in the prompt about truncation that will add the value for you. (OR as James said, have a search/filter option)
2. organise the Values in some sort of order ( alphabetical would be my preference) Currently it appears to be totally random.
For Example - It currently appears as DOMAIN\group name for AD groups.
but the groups appear something as per the list below (making it near impossible to locate a group you need to find - currently, I go to the DC, locate the group, copy the name, go back to the collection and paste it in.)
There are other posts here in UserVoice, requesting improvements to the query process that may also be looked at if this one is. Might be able to resolve several posts with any changes made in this area.
- A better editor for collection query statements
- Easier access to collection query editing
- Make it simpler to author collection query rules
agreed, maybe make it smart enough to prompt you with - "these are the dependencies, would you like to remove the links to these applications"
Updated by bobmn for sangeev/OSD
So if I understand this right, I plug in a new model computer, pxe boot and when the build gets to the driver install component, either SCCM goes off to Dell-HP-Lenovo or a central repository controlled by Microsoft, downloads the appropriate driver cab, adds the drivers to SCCM and installs them on the computer. Sounds Awesome to me if that is the concept.
I think any catalogue hosted locally would need to be metadata only and drivers retrieved from another location as storing all possible drivers locally on each SCCM server would require too much storage.
Apologies – my error – reverting status back to noted. This request is not addressed in 1905 Technical Preview.
Updating this item as there’s support for Windows 10 In-place upgrade using the Cloud Management Gateway – see https://docs.microsoft.com/en-us/sccm/core/plan-design/changes/whats-new-in-version-1802
Adding this in case some folks missed it or Win 10 In-place upgrade addresses their requirement.
I recognize this it not full OS Deployment as there’s no WinPE phase (WinPE has no wireless stack)
17 votesNoted · AdminMark Silvey - ConfigMgr Product Team (Engineering Manager, ConfigMgr, Microsoft Endpoint Configuration Manager) responded
This makes sense to me. Surprised no more support than this..
799 votesstarted · Admindjam (Product Director, or Executive, Microsoft Endpoint Configuration Manager) responded
Try this out over CMG in #SCCM TP 1906