Force Client Deployment on metered network
We have several users who are ALWAYS on metered networks and will never get client updates.
The client deployment currently does not honour the option "Client Setting - Specify how clients communicate on metered network connections".
We need an option to override it for manual client deployment / update as well. (Force install checkbox doesn't work)
Setting the connection to "not metered" in Windows 8.1/10 doesn't work when a 3rd party connection software is used and doesn't work at all for TCT Mobile LTE sticks so this is not a solution.
Christoph von Wittich
shared this idea
10 comments
-
92d4-ad940dc7a333
commented
Why isn't this fixed ?
-
Anonymous
commented
We are experiencing the same behaviour, In Windows 10 1709, a user can set the Ethernet connection to a Metered connection. There is no GPO to prevent this. Once set the SCCM Client cannot install, As soon as it is removed, which you can only do from the OS the client installs without a error.
This seems to be a major issue, as there is no way for a admin to control the users from doing this, and once set a admin needs to do a RDP session to remove.
-
Dennis Abbott
commented
This WMI setting is marked as Read-Write but it does not work, the provider comes back and says it is not-writeable.
set-wmiinstance -class ccm_NetworkSettings -namespace root\ccm\clientsdk -Argument @{MeteredNetworkUsage=0}
set-wmiinstance : Provider is not capable of the attempted operation
+ CategoryInfo : InvalidOperation: (:) [Set-WmiInstance], ManagementException
+ FullyQualifiedErrorId : SetWMIManagementException,Microsoft.PowerShell.Commands.SetWmiInstanceEven checking the property with get-cimclass confirms that the ReadOnly flag is not there, this is not working as expected. Fixing this would make an easy solution.
$a = get-cimclass -class ccm_NetworkSettings -namespace root\ccm\clientsdk
$a.CimclassProperties['MeteredNetworkUsage']Name : MeteredNetworkUsage
Value :
CimType : UInt32
Flags : Property, NullValue
Qualifiers : {}
ReferenceClassName : -
Phil Chatham
commented
we still can't update the latest client to our mobile laptop estate!
we really need a way to allow our client to be upgraded! -
Phil Chatham
commented
Thanks for the workaround - I don't think you can set this property?
I have followed the documentation but cannot change to '0'
https://msdn.microsoft.com/en-us/library/jj885733.aspx
if you can shed any light or post an example? -
Bea
commented
For workaround you need to change locally the value of CCM_NetworkSettings locally on client to allow metered connection to be assigned and get the client settings policy
-
Chris Allison
commented
We have exactly the same issue, our devices are permanently on a metered connection and will never receive the upgraded client - please help!!
-
Phil Chatham
commented
This would be so Usefull!!
We have so many mobile only devices...
We can allow deployments via the Client settings - but we can never get the client upgraded or repaired even when specifying a local /source
-
Phil Chatham
commented
This would be so Usefull!!
We have so many mobile only devices...
We can allow deployments via the Client settings - but we can never get the client upgraded or repaired even when specifying a local /source
-
Nishan Gonsalkorale
commented
I know this was nearly a year ago, but did you ever figure this out?
My problem is maybe the other way around, but the behaviour i'm seeing doesn't really make sense!
I have machines that are sometimes on a metered connection. All deployments are 'required'. According to what I've read (and since tested) when I set the client settings to 'Limit' it allows all deployments when they've reached their deadline! Well, that's all of ours, so what's the point in the tick box in deployments that states that it allows deployment on metered connection when deadline is reached...it always would!?
I'm struggling to get metered connection clients to receive SCEP definitions and occasional patches through Direct Access and yet deny all the rest unless they're connected locally to the LAN...