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?

I actually ran into something similar earlier this week. Are you sure they're not already in process, and just waiting on a reboot? For my case, it was a matter of a pending reboot. Updates targeted to machines had the reboot suppressed. They had run through installation, and were waiting for users to reboot. SCCM reporting, at that point, showed them as not required. Once these systems were rebooted, the updates started showing as installed.

Once it's in WinPE, in that command window, can you run ipconfig and see if you're actually getting an IP address?

Ahhh, didn't realize you meant that the bluescreen was happening in WinPE.

Hi, all. Got a weird one, here... We have two separate organizations that work closely together. Call them A and B. A's remote sites connect to each other in a datacenter. A's servers live in the datacenter. A's offices are connected to that datacenter. B's remote sites connect to each other in a datacenter. B's servers live in the datacenter. B's offices are connected to that datacenter. A's and B's networks converge in shared office space. A's remote sites <--> A's Datacenter <--> A's offices <-->B's offices <--> B's datacenter <--> B's remote sites A's network policies don't allow traffic to/from the remote sites to get past the datacenter for most remote endpoints. E.g. one of A's central office computers has zero connectivity to a domain controller or workstation at remote site A1. A's and B's network policies do allow traffic from as far away as B's datacenter and a couple of B's remote sites to get to A's datacenter. These connectivity restrictions are not routing issues, but something akin to ACLs (I'm a cisco guy, and A's gear isn't cisco, they have some other name for essentially the same sort of thing). We have users in A's offices that require CMRC access to workstations in A's remote sites. We may soon have users in B's offices and/or remote sites that will need CMRC access to workstations in A's remote sites. To this date, Config Manager users have worked around this by simply using RDP to connect to the Config Manager server (which lives in A's datacenter) and launching the remote control from there. The additional remote control users that are or may soon be coming online are not ones that A would like to have logging into their Config Manager server, for various reasons. Changing network configs to pass the traffic is not an option at this time. Anyone know of a way to work around this? I know I could throw up a VM or two in A's datacenter with cmrc on them and have the new remote control users connect to that with RDP and go from there, but I'm wondering if there's a better way. RemoteApp server in A's datacenter? Anyone know of some way to proxy *just* the cmrc traffic for these users' workstations, so that as far as the network gear is concerned, the endpoint lives in A's datacenter, and therefor can talk to A's remote sites? Doesn't seem to be any way to have the cmrc client bounce traffic off the Config Manager server, or anything along those lines.

Ended up just making three collections - one for 32-bit, one for 64-bit, and one that includes both of them. :\

Yep. I suppose you could just use a LIKE compare, too. E.g. LIKE %Workstation 6.1% Strings for others would be: Workstation 6.3 = Windows 8.1 Workstation 6.2 = Windows 8 %Windows%10.0 = Windows 10 - I forget why we used a wildcard, maybe because the edition's in there?

Be careful with that one - looks like it'll get Java-related stuff, as well. E.g. "Visual Studio Extensions for Windows Library for JavaScript" gets caught by that. Also won't get 32-bit installs on a 64-bit OS, since those live in hklm\wow6432node\microsoft\...

Looks like one we were seeing that came from a bad HDC driver. Config Manager was picking a newer, "better" version of the driver these systems (Dell Optiplex 7010) needed from a driver package recently added for some new hardware (Lenovo T440) during the Auto Apply Drivers step. It obviously wasn't a good pick, as it caused the Optiplexes to BSOD. Solved it by ditching the Auto Apply step (except as a last resort), and instead set our task sequences to install driver packages matching the hardware, based on conditions.

FWIW, we use the criterion "System Resource - Operating System Name and Version" and check that it's equal to "Microsoft Windows NT Workstation 6.1" It's been so long, I don't remember the reasoning, but I want to say it's because the Operating System - Caption doesn't get populated until a hardware inventory cycle runs and returns info from (WMI on the?) the client, whereas the System Resource category gets populated as soon as the client reports in to a server. If anyone can verify, that might be useful info. If I set up a collection with your parameters, it's missing about 50 systems that are/were out in our environment; those systems do show up in the collection built on the System Resource criterion.

Regular offline installer exe. Run it, click past UAC prompt, and then stop. Look in %appdata%\LocalLow\Oracle\Java\ - there'll be subfolders for whatever version(s) you're dealing with. MSIs are in there. Replace Oracle with Sun if you're dealing with older versions (8u45 and earlier, 7u...??? everything? haven't messed with the final builds).