The good news is there is a built-in and supported way to accomplish this! It's just not documented anywhere.

1. Go to the Collections node and click in the Search bar at the top
2. This will bring up a new tab on the ribbon named 'Search'
3. On the search tab, click 'Search Settings'
   
4. Change the value to what makes sense for your environment. Keep in mind, this has performance impacts for your local console.
   

Now whenever you select a collection, it will by default display the number of clients or users that you've specified in the Search Settings.

This is on a per-console basis, so if you go to a different workstation, or re-install the SCCM console it will reset to the default 1,000 results.

The errors are associated with these events:

Increasing the thresholds from default was necessary to maintain the service. Here's what I found to work in a customers production environment:

1. On your WSUS Server, launch the IIS Manager
2. Open Application Pools
3. Right click 'WsusPool' and select 'Advanced Settings...'
4. To support the maximum SCCM Software Update Point clients, change 'Queue Length' from the default 1,000 to 25,000
   
5. If your server is NUMA aware, change 'Maximum Worker Processes' from the default 1 to 0. If you don't know if your server is NUMA aware, leave this value default
   
6. Change '"Service Unavailable" Response Type' from the default HttpLevel to TcpLevel
7. Change 'Failure Interval (minutes) from the default 5 to 30
8. Change 'Maximum Failures' from the default 5 to 60
   
9. Click 'OK' to save the App Pool changes
10. From an administrative command prompt, type IISRESET

Your clients should now be able to check-in to the Software Update Point / WSUS service.

If you've spent any time with Configuration Manager Hardware Inventory, you know that it can be a little bit finicky and prone to failure if not configured correctly. I'm going to describe a fix that I implemented for a customer recently where the Inventory data loader (located at <ConfigMgr Installation Directory\Logs\dataldr.log) reports the following error:

CMachineSource::InsertMachine - Top Level group not found.  All MIFs require a group that is the same name as the architecture.

And the MIF files from clients will be moved to <ConfigMgr Installation Directory>\inboxes\auth\dataldr.box\BADMIFS\NonExistentRow

Steve Rachui has a great and very in-depth blog article located here:
https://blogs.msdn.com/b/steverac/archive/2010/11/22/the-case-of-the-mif-and-wmi-repository.aspx

In every case I have discovered, the only way to recover from this specific error is to re-install the SCCM client agent. The primary reason for this behavior is because the initial inventory MIF is supposed to create a row in GS_WORKSTATION_STATUS, and if you misconfigure hardware inventory, it could prevent the hardware inventory from adding this row, which will prevent all future inventory data coming from that client, and even triggering a "Full Hardware Inventory Sync" will not create the row.

Starting with Configuration Manager 2012 SP1, we added the /forceinstall parameter to ccmsetup.exe. Basically, what this parameter does is tell the existing ConfigMgr client agent to uninstall first and then install the client. This is very important, because simply installing the client over the top of the already installed ConfigMgr client will not actually fix the issue. Steve does a great job identifying why the client behaves that way, and he also suggests uninstalling/reinstalling the client.

Here is the process that I've created to successfully uninstall and reinstall the client agent, and I have verified on several hundred clients that this works. The best part is that you can deploy this through ConfigMgr packages and maintain the deployment history!

1. Configure a new Package in SCCM. Software Library > Application Management > Packages
2. Right click Packages and click Create Package
3. Name the package "Reinstall ConfigMgr Client" and leave "This package contains source files" unchecked. Click Next
   
4. Leave the 'Standard Program' radio box selected and click Next
   
5. Name the program "Reinstall ConfigMgr Client" and change 'Run: to Hidden' and 'Program can run: to Whether or not a user is logged on' and click Next
   
6. A good recommendation practice is to change the Program Requirements 'Estimated disk space' to 150MB just in case the client has run out of space on the OS drive
   

For reference here is the command line that I've used to successfully performed this task:

%WinDir%\ccmsetup\ccmsetup.exe /forceinstall /mp:<Management Point FQDN> SMSSITECODE=XYZ SMSMP=<Management Point FQDN> FSP=<Fallback Status Point FQDN> DNSSUFFIX=<Domain DNS Suffix> SMSCONFIGSOURCE=P

Once you have created this package, you should double check that "Source content" is still unchecked. Right click the 'Reinstall ConfigMgr Client' package and click the 'Data Source' tab. At the top uncheck the 'This package contains source files'. I'm not sure why this checkbox misbehaves, but I've seen it not respect what you've chosen in the Create Package wizard.

Deploy this package to the clients that need their hardware inventory remediated. If you're going to do this on hundreds of clients, I would recommend phasing the deployment to 10% chunks of total clients to be remediated so as to prevent backlogging.

From this point, the initial hardware inventory will trigger automatically.

I won't get into the details of actually configuring the custom inventory, but I can say it involves creating a new WMI class and adding that to your inventory policy. The best way to perform that is to use baseline configurations, but let's say there are clients that don't create this new class. You will get errors for those clients, and they may stop performing hardware inventory altogether, which could cause backlogging.

When you do this custom hardware inventory, it's very important to target the inventory policy to the clients with the custom WMI classes. If you're using baseline configurations as in my example, you can easily create a dynamic query to add those members, and then deploy the Client Settings to that collection.

Here's the query for my specific baseline. As you can see, I've filtered it to Client Installed = 1, the Baseline scope ID, and finally Compliance State = 1.

Here is an example of a new Client Settings policy specific to Hardware Inventory Local Groups.

Now all you need to do is deploy this Client Settings policy to the dynamic collection and you'll be golden!