Jaybone

Update: ~20 hours later, that job has transferred a whopping 20MB. 0_o

Hi, all. Came upon something I've not seen before. Trying to push the Config Manager client to a new server, it was going excruciatingly slow. Reading up on it led me to look at BITS stuff. Settings were all good - non-existant, actually. The only thing that helped was to change the job's priority from Normal to Foreground. That got the transfer done more or less instantly. So now the client's installed, but there are new BITS jobs stacking up. I can't get any Windows Update info from it to the CM server, etc. Now, this server sees a sustained 250-275mbit/s of inbound network traffic pretty much all the time, just by nature of the type of server it is. That leaves several hundred mbit of slack, though, as it's got a 1gbit connection. But BITS seems to be acting like its starved for bandwidth, and transfers are slow, even when the CM client is setting priority to high. We've got a server that fills an identical role and is running on identical hardware with the same NIC driver on the same network that sees even higher sustained inbound traffic (currently ~1.2gbit/s on a 3gbit/s team), but without any of this type of problem. Anyone know of a way to force BITS to be a bit more aggressive, so that things actually work? Or maybe I'm going about this wrong? E.g. ~22.5 hours after it was created, this WU job finally started, and 20-30 min after that, is only 7MB along. PS Z:\TOOLS\pstools> Get-BitsTransfer -allusers -name "wu*" | fl JobId : b70f15ba-cb48-4cbb-9487-fec406bcc230 DisplayName : WU Client Download TransferType : Download JobState : Transferring OwnerAccount : NT AUTHORITY\SYSTEM Priority : High TransferPolicy : NoSurcharge FilesTransferred : 0 FilesTotal : 1 BytesTransferred : 7577239 BytesTotal : 96814352 CreationTime : 1/23/2018 2:58:51 PM ModificationTime : 1/24/2018 1:50:56 PM MinimumRetryDelay : NoProgressTimeout : TransientErrorCount : 0 ProxyUsage : NoProxy ProxyList : ProxyBypassList : Others are still queued up. PS Z:\TOOLS\pstools> Get-BitsTransfer -allusers | ft displayname,creationtime,modificationtime,priority,jobstate DisplayName CreationTime ModificationTime Priority JobState ----------- ------------ ---------------- -------- -------- CCMDTS Job 1/23/2018 2:16:53 PM 1/23/2018 2:16:53 PM Low Queued CCMDTS Job 1/23/2018 2:16:53 PM 1/23/2018 2:16:53 PM Low Queued CCM Message Upload {1B2D... 1/23/2018 4:22:46 PM 1/23/2018 4:22:46 PM Normal Queued CCM Message Upload {098C... 1/23/2018 6:28:45 PM 1/23/2018 6:28:45 PM Normal Queued CCM Message Upload {F0B2... 1/23/2018 8:05:32 PM 1/23/2018 8:05:32 PM Normal Queued WU Client Download 1/23/2018 2:58:51 PM 1/24/2018 1:53:51 PM High Transferring CCMDTS Job 1/23/2018 12:55:51 PM 1/24/2018 1:44:22 PM High Queued CCMDTS Job 1/23/2018 12:31:08 PM 1/24/2018 1:49:22 PM High Queued

Update of a sort: Yesterday - ran ccmsetup /uninstall and watched uninstall log and event log for completion Rebooted when it finished removed ccmsetup folder and remnants of ccm folder Verified with WBEMtest that root\sms no longer existed. Pushed install from server stepped back to give things some soak time Today - same old nonsense CmRcService insta-disables itself and logs that we've disabled it SendSchedule.exe /L only returns six things sending it an Evaluate Machine Policy schedule says it's successful, but nothing changes, and PolicyEvaluator.log instantly shows "Settings update not required. No changes detected." PolicySpy against it still missing most stuff it should have, but does show three advertisements under CCM_SoftwareDistribution Other systems in the same remote office are fine. I still can't make heads or tails of this. Anyone got any ideas?

Hi, all. Scratching my head here, and hoping someone has some insight on this. Sometime between last Thursday and yesterday, Remote Control stopped working on at least one device in a remote office. The service instantly disables if it's manually changed back to Automatic (delayed). It does fall within a boundary used for site assignment. Remote Control settings are set at both the default policy level and in a policy applied to a device collection this thing is in, both set to allow. CmRcService.log claims that The ConfigMgr administrator has disabled the Remote Control feature for this machine, Remote Control Service will be disabled now. Which... no. We didn't. Resultant client settings look fine, showing RC should be enabled. PolicySpy looked all wrong, though. Requested/Machine/Settings only had five things in there, and none of them are CCM_RemoteToolsConfig. Actual/Machine/Settings... I don't remember. I went as far as removing and reinstalling the client yesterday afternoon. It wanted a reboot but the user was in the middle of stuff. I used sendschedule to tell it to do a machine policy cycle, which claimed to have succeeded. After that, either Requested/Machine/Settings actually looked normal, or I was looking at the wrong PolicySpy window. :\ As of this morning, it's not working, and PolicySpy results look all wrong. Requested/Machine/Settings only has five things still, and while Actual/Machine/Settings has a ton of stuff, the RemoteToolsConfig branch is missing. Sendschedule /L only comes back with five things (Request Machine Assignments, Evaluate Machine Policies, Refresh Default MP Task, Machine Policy Agent Cleanup, Policy Agent Validate Machine Policy / Assignment, Retrying/Refreshing certificates in AD on MP). Sending any of them returns a success, but nothing ever changes. LocationServices.log looks good. Last Activity in the console updates periodically (right now showing the timestamp of when I sent the Evaluate Machine Policies schedule). Anyone know what the heck I'm looking for, here?

Running 1610, I stumbled across something yesterday, and I'm wondering if anyone else has seen this: changing just the name of a query used to populate a collection breaks the collection. Steps to replicate: Change the name of the query being used as a membership rule for a collection. Collection's icon gets an hourglass, even though nothing about its membership actually changed. Hourglass doesn't go away, and collection membership no longer updates. The first time I saw this was with a query-based collection looking for %server% in operatingSystemNameAndVersion. Even after adding new devices to the environment and waiting overnight, those devices didn't get pulled into the collection this morning, even though delta was enabled so they should've been picked up within minutes. "Fixed" it by deleting and re-creating the collection. I have another, separate 1610 environment I work with regularly, so I jumped over to that one and created a new query-based collection to test with, looking for %string% in the system's name. Changed the name of the query, and sure enough, the collection's hourglass refused to go away (only left this one for 15 minutes, not overnight). Changing the actual query to %string2% seems to have gotten the collection working again, though obviously isn't really a fix, since string and string2 are different; just need to change back to the original string. Back to the initial environment, with a collection looking for system name ending with a number and a specific service existing and being set to auto-start: change the name of the query, and the hourglass has been stuck for 30 minutes. Changing the query in some non-meaningful way (adding a second space character after an "and") doesn't help. Changing the query in a meaningful way (look for a different service name) gets the collection working again. So it doesn't seem to matter what the query is looking for - three queries looking for three different things (though second and third are similar) and all of them break the collection if just the query name is change without changing the query itself.

Thanks, Niall

For Office 2013, MS themselves still recommend 32-bit unless the 64-bit functionality is specifically needed. Or has that changed? As far as the OS... some of us are still stuck running 16-bit legacy garbage that can't be run on a 64-bit OS, with no time or budget to get it converted to something more modern. If one has the time to implement virtualization to get around that, great, but not everyone does.

I could find approximately nothing with Google, other than the standard documentation, which is either wrong, or I'm completely misunderstanding. From its own help: SYNOPSIS Gets Configuration Manager alerts. Example 1: Get all alerts PS C:\> Get-CMAlert Except it doesn't. It misses a ton of them. On our new 1606 site, it returns only 17 of 28 alerts, and none of the ones I'm actually interested in (SCEP alerts). In another forest with 2012 R2 + CU3, it returns 186 of 192. Better, but still not all. Are certain things, e.g. SCEP alerts, not considered "Configuration Manager alerts" or something, even though they show up in Config Manager's alerts workspace? If that's the case, anyone know how to determine what type of alerts those are, and how to interact with them?

Anyone seen this? It only appears to be affecting Office 2010. Updates, generally older ones, that meet the criteria for installation - Office 2010, not superseded, Security or Definition Update categories. They're not getting installed. A report run against a computer that shows as needing them comes back with some updates only marked Required, while others are marked Required and have a deadline, but none of them show as being approved. How can an unapproved update get deadlined, and if it meets the criteria, why isn't it approved? Blowing up all Office 2010 update groups and creating a new single update group for Office 2010 via a manually run, unscheduled ADR didn't help, just put today's date on the offending updates. Also confused as to why multiple old definition updates show up more than once (KB982726 from Sept 2014) and don't show as superseded (e.g. by KB3115475 from August 2016) , even though they're for the same thing (Outlook 2010 Junk Email Filter), albeit with different KB numbers.

Alternatively, you could have three collections: 1 = AppNameCollection 2= ExeVerCollection 3= ComboCollection - instead of query, just include AppNameCollection and ExeVerCollection I forget the details of why, but I've had to do this for Java, to get both 32-bit and 64-bit instances into one big collection - trying to write a single query that would catch both would just not work as I expected. My expectations were probably wrong, heh.

Try unchecking unknown computer support, restarting WDS service, re-checking unknown support, restart WDS service again, and see if it starts working?

Sorry, but this really deserves a... http://lmgtfy.com/?q=80220014+sccm

After changing up my search terms, came across this same type of question on Technet, answered by Garth and others. https://social.technet.microsoft.com/Forums/en-US/0f096508-2440-456e-ae78-72f4e4271a89/installed-applications-version-is-less-than-sort-order?forum=configmanagerapps Apparently it's a string comparison, not numeric, so yes, the leftmost digit being 9 vs 1 explains it.

How big are these apps, and how big are the client caches? I don't remember the details, but we saw something similar when deploying the Dynamics AX client. The default cache size is, I want to say, 5GB. The AX install was 7+GB. Clients would try to install it and fail since the app was too big to fit in the cache. Solution was to increase the cache size on the clients. I'm not familiar with the specific Autodesk stuff you're using, but in my experience with Autodesk Infrastructure Design Suite, I know their installers can run to the tens of GB, so you might be running into this same thing.

We've always had collections set up so that we could tell quickly which clients had installs of Java below a certain patch level. Our criteria for this was to look for: Installed Applications.Display Name is like "%java 8%" and Installed Applications.Version is less than "8.0.XYZ" for 32 bit installs, and a corresponding collection for the 64 bit ones, where XYZ corresponded to the current version. Java 8 Update 91 was 8.0.910. With the new version that came out the other week, Java 8 update 101, that version number is 8.0.1010. I'm wondering if that switch from 3 digits to 4 digits is significant, here, because... The problem that we're seeing now is that these queries are returning unexpected results, with empty collections - e.g. saying that no Java installs are earlier than 8u101. I created a new collection with the opposite criteria, instead looking for Installed Applications.Version is greater than or equal to "8.0.1010" (and later tried 8.0.1010.0). This new collection contains every computer with any version of Java 8. Apparently either: 1. Config manager sucks at math, thinking that 910, 750, 650, etc are larger than 1010. or, more likely 2 I'm not understanding version numbering If 2. I'm thinking maybe that the leftmost digit is the most significant, so 9 is greater than 1? Anyone have any insight into this?