spgsitsupport

All it does, is to add ClientUpdate folder to existing Client package & re-distributes it to DP (so next clean install will do the upgrade at the end of normal installation) Seb

You could always have secondary PXE menu on another server with iPXE, which would allow boot of iso from http Seb

No, it is impossible otherwise. HTTPS is a must requirement, otherwise Mac will not talk to SCCM Seb

It seems that all devices in collection updated day after (once the night maintenance window expired) Which makes no sense to me (like lots of SCCM doings) How would one update definitions ie every 6 hours? Seb

Read that, made sure Maintenance Window is specified for collection. No difference. Why is that so difficult to apply as simple thing as definition updates? Kaspersky has it perfectly spot on with own agent/console Seb

OK, so what does the above description actually mean? Like; "...future client installations using the Client Push method will apply the new patch automatically." Automatically HOW? Seb

Nobody noticed this same? Nobody using it this way? I have now tried number of times & the end result is always the same, DUPLICATION of the record Seb

Followed this. Have it all created this way, once WSUS gets new definitions the rule DOES work, the new definitions are added to the package, DP are updated. But it does NOT actual do the "exciting" part of applying these definitions to the specific (Software Update Group) deployed to Collection So end result that SCEP clients are not updated What could I be missing? Thanks Seb

http://blogs.technet.com/b/configmgrteam/archive/2015/08/04/automatically-updating-the-configuration-manager-client.aspx "Choosing the “Automatically apply” option results in the installer performing the following steps: Places the most recent client patch file on the site server. Updates content on the distribution points for this site and any child sites. Note this only occurs when the cumulative update runs on the Central Administration Site (CAS). Updates the client package on the Management Point of the local site; this source is used in the event there are no distribution points available for client installation. Note that in the case of a hierarchy, the cumulative update should be run at child sites to update their local Management Points as well. In addition to the above, future client installations using the Client Push method will apply the new patch automatically. The time frame for updating the client depends on the automatic client upgrade settings. Note that the client version displayed on the Automatic Client Upgrade tab of the Site Settings Properties dialog box will not change with the installation of a cumulative update." and http://blogs.technet.com/b/configurationmgr/archive/2015/08/04/cumulative-update-1-for-configmgr-2012-sp2-and-configmgr-2012-r2-sp1-is-now-available.aspx CU1 update CM12_SP2R2SP1CU1-KB3074857-X64-ENU creates CU1 KB3074857 - x86 client update & CU1 KB3074857 - x64 client update packages But how do already installed clients get updated? Do I need to Deploy above? None of the above makes much sense to me (I see nothing like: Updates the client package on the Management Point of the local site...) CU1 client is 5.00.8239.1203 , but so far none of my workstations got updated to it (still on 5.00.8239.1000) Thanks Seb

I will never have another site, period. As I said, it is in many case easier for me to re-create just the source folder then bother to triplicate it via DP I can not stand the mess the DP is, with orphaned files left over like in a rubbish bin

OK, that is one way of doing it... (did not think about doing it this way) Obviously script is executed with system privilidges, which I assume does cascade to the actual application execution as well, right?) Seb Yes, it does, exactly what I needed. Really hate the design of SCCM...

We Well, Applications do not seem to work, no matter what settings I try. I hoped that Allow clients to use a fallback source location for content would do the trick, but it seems that no matter what, I get Error 0x87D00607 like per this Packages with Programs work perfectly fine directly from UNC only

Sadly no matter what I do, the objects gets re-created in SCCM with IDENTICAL GUID

In the pictures above the BIOS GUID is (each part) in reverse order. Why is that? It explains why the manually created object is "different" then SCCM registered machine. I expect that if manual creation was in reverse order then the object would be re-used Seb

Package works fine, but I still think that SCCM with everything (applications and/or packages) is a mess with too many options in one place & none in the other...

OK, no problem with targeting then, but have no idea what condition could be used for Detection Method (as they are BIOS only settings that can not be read from within Windows) Again it looks like Application is not the way to do it Seb

Easy to say, but honestly if you have technicians that are supposed to ie produce/maintain "something" creation for software distribution, then it does make it REALLY CONFUSING which one to use for what purpose. So it does end up with all being made into one or the other (could be right or wrong), as it is too logically time consuming to figure out which one could/should be right for the situation. Mess IMO Seb

Thanks guys, much appreciated Seb

How can one target application at specific hardware model? Or Application would be not the choice? BasicallI need to run Dell BIOS settings on-mass on all machines that are xyz model Thanks Seb

Ah, so it uses the rule NOT ONLY for check before install, but also for check AFTER install. Which makes life difficult if one needed Application to only execute something (behaving like shortcut) Live and learn...

Thanks, sadly confirmed what I expected (but can work around it) Seb

How seriously counter intuitive that is! Things that could be simple now require many additional steps. Scenario: run a file from cccache (that gets downloaded from DP), which all it does is service install (copies itself to syswow64), THEN I need to copy the service executable from syswow64 to system32 (please do not comment on the action or wonder why - simply that how it needs to be!) So it should be an easy - action 1 = run file (depended on) action 2 = copy file (deployed) Now I need to create 2 applications (figuring what kind of logical names to use), make one depend on the other & then deploy the last one to the user/workstation At which point the application that deployed application depends on gets installed with exist code 0 (action 1 success), but the 1st application is ignored (action 2 - no single mention of it in AppEnforce.log) and user gets Failed Seb

I do have an Application (not Package with Program) that I need to run on every user logon (and I do NOT want to use logon script in case somebody wants to suggest it) Is there a way to do it? SCCM seems to be lacking logical ease of use found in other products Thanks Seb

That script being what? Unmodified 8u60 msi just chokes & insist on running from exe Seb

That used to be possible: http://www.techygeekshome.co.uk/2013/04/java-client-updates-deployment-using.html Then with edited msi: http://www.klaus-hartnegg.de/gpo/msi_java8.html but now with Java 8 Upd 60 I could not get it working (edited msi give 2705 error) msi can be extracted or downloaded from http://java.techygeekshomeSPAM!/instructions What are people using for java updates? Thanks Seb