Partager via

Are your new clients working?

  • Article

I have setup many SCCM installations in my time and once I have all the server side pieces in place I like to kick a few quick tests to make sure it is all working as expected.  Nothing too heavy and cumbersome, but enough to see if you have a good foundation to build from.  Depending on time constraints, how much is setup, etc. I have “option 1” and “option 2”.  I prefer Option 2 because it exercises just a little bit more of the system.

 

Option 1

  1. Install a client
  2. After install go to the control panel and kick off a hardware inventory cycle
  3. Check resource explorer on the site server in about 5 minutes and make sure there is inventory listed for that client.

This validates that the admin UI is talking to SQL correctly, that the client can correctly communicate with the management point, that the MP can correctly communicate back to the the database, and that the site itself is able to process files and load them into the database.  A good solid foundation

Option 2

  1. Setup a test package with something in it, like calc.exe.  What you use really isn't terribly important as long as there is at-least one file, preferably a fairly small one.
  2. Make a program for this package and run calc.exe.  Note that calc.exe doesn’t need to be in the source files but should be found on the local system.
  3. Install a client then deploy an optional deployment to your new clients of the above program and package

In addition to all the things that option 1 validates above, this also validates proper communication with the distribution point, a key part of the base infrastructure.  Even though calc.exe isn’t in your package, if there was a failure to get the package content down then the execution should fail.

These tests will work on anything from SMS 2.0 to SCCM 2007 and SCCM 2012.  The new application model in SCCM 2012 opens up some other fancy possibilities, but they can’t really validate more than the application catalog roles.

There are fancy variations on these things, to be sure.  The “next level” is to use option 2 to deploy a simple script and copy cmtrace.exe or smstrace.exe onto the client for future troubleshooting needs.  If anyone has their favorite “quick test” please add it in the comment section.