DirectAccess Changed My Life

Anybody who has ever been a Systems Administrator can attest to one thing: there is no such thing as “after hours.”  In today’s society, this statement holds even more truth, as monitoring tools, email access via Internet and smart phone integration have become part of every IT professional’s life.  If you ever find yourself at home deep into a movie or out with friends enjoying a beverage, inevitably your pocket will vibrate with a friendly reminder that, although you are physically away from work, you are never really “away from work.”

Thankfully, my employer understands how taxing this can be and tries to ensure that we are on the cutting-edge of technology, making our always-on way of life a little less stressful.  One of the greatest connectivity tools that we have introduced to our environment is DirectAccess.

With the increasing need to be available at all times and anywhere, the flaws of relying on VPN become more and more evident.  For example, you may have no issue connecting through your controlled environment at home, whereas the security rules in your local Internet Café slap you back Dikembe Mutumbo-style.  If you are lucky enough to get connected, chances are that you will have to make several attempts due to timeout issues, or the connectivity provides a less-than-desired experience.

DirectAccess will allow you to automatically connect to your corporate network EVERY TIME an Internet connection is available.  That means, wherever you are when “the sky is falling” at work, you can simply open the lid of your mobile workstation (or, in my case, tap my Surface Pro for nearly instantaneous results), connect to wi-fi and immediately access shared folders, internal network applications, etc.

The use of DirectAccess not only relieves some of the stress of the IT administrator’s life, but it also improves accessibility for the end-user.  Undeniably, not every user in your organization understands VPN, from initiating a connection to whether or not they have an established session.  DirectAccess not only ensures that the steps that a user has to take to launch VPN are no longer a factor, it also guarantees that the employee will be able to access internal resources, whether it be shared folders, intranet sites or email (if OWA or Outlook Anywhere are not already configured).

Naturally, DirectAccess is not a solution for every environment.  There are certain limitations, such as legacy OS compatibility (both client and server side), inability to utilize a non-domain joined machine, etc.  However, many inferred “shortcomings” have very easy workarounds, and we will show you an example in a future post “DirectAccess:IPv6 in an IPv4 Environment.”   Comparatively, the benefits of utilizing DirectAccess over VPN far outweigh the shortcomings, especially as your infrastructure continues to advance into the future.

SCCM – Local Administrator Inventory via MIF

Have you ever wanted to collect local administrator information on a regular basis? If you have ConfigMgr, here’s how to do it. We gave you some background recently through Jesse’s post about MIF files found here.

Here’s what we’re going to accomplish:

  • Gather the members of the local administrators group on all Windows clients and servers
  • Ensure the data is updated regularly through the use of ConfigMgr’s hardware inventory cycles
  • Extend ConfigMgr’s HWI classes to add the Local Administrator information in Resource Explorer as seen here:

96

We need to set some ConfigMgr client agent properties, so navigate to Administration Node > Client Settings > choose the client settings to modify > and select Hardware Inventory. A couple of modifications to the properties of Hardware inventory – Collect MIF files and change the Custom Inventory Size (optional) as seen here:
1

Now, you’ll need to create the MOF file to extend the ConfigMgr inventory classes. Here’s the MOF I created for the Local Admins solution:
5
Here’s the .DOCX file so you don’t have to retype: MOF

After you have your MOF created, you’ll import the MOF into Configuration Manager. In the hardware inventory area of the client properties, select ‘set classes’ as seen here:
2

In the hardware inventory classes properties, select ‘import’ and import your MOF you created earlier, as seen here:
3

4

Ensure you see the success on the import like this:
6

To verify, in the hardware inventory classes screen, search for local and ensure the follow occurs:
7

The hardware inventory class has now been extended. The next step is to generate a MIF file on a regular basis. The method I’ve used in the past is to run a recurring deployment/advertisement that executes a script (VBS in this case, soon to be updated to powershell). Here’s the VBScript I’ve used in the past:
8

9
And here’s the .DOCX file so you don’t have to retype: script

Here is the pertinent parts of the deployment:
91

92

93

Here’s the default location of where the MIF is written once the script is executed:
94

This is what the MIF should look like when opened with Notepad:
95

Here’s the end result:
96

Write me an E-mail or comment on this post with questions. Enjoy!

Update: I forgot to mention, the path for MIF in the VBScript will need to be updated for Site servers. You can use requirement rules, or the good ol’ fashioned way of controlling deployments via collections to control what scripts are running on what clients/servers.

SCCM Hardware Inventory Got You MIF(fed)?

Look at you!  You just installed SCCM 2012, deployed the agent to a majority of the client workstations in your environment and began collecting hardware inventory information.  However, after tearing through the gathered data, you come to the stark realization that you cannot query based on computer asset number!  How angry you must feel, spending all of that time designing your new SCCM environment only to be met with unforeseen limitations.

Be miffed no more, my friend!  Well, kind of…let me explain.

Certainly, the out-of-the-box hardware collection capabilities are quite robust.  SCCM utilizes Windows Management Instrumentation (WMI) to access management information from client machines and then returns the data into a recognizable format on the site server.  To some, however, this collected information can leave much to be desired.  Luckily for you, Mr. Overachiever, there is a way to extend SCCM’s hardware collection capabilities: the utilization of MIF files.

Management Information Files (MIF) are used by SCCM and clients to exchange hardware information.  With the out-of-the-box capabilities of SCCM, you can enable and disable WMI classes, as well as add new classes, by manipulating the client settings.  When utilizing MIF files in conjunction with the default client agent classes, hardware inventory becomes even more granular.

There are two types of MIF files: NOIDMIF and IDMIF.  NOIDMIF files extend the capabilities of hardware inventory on client devices, while IDMIF files are used to collect information about other non-managed (yet, network-associated) devices.  During the hardware inventory cycle, all of the information stored in the corresponding MIF files augments the client inventory report.  The gathered data is stored in the site database and you can utilize the information in the same way that you use the information provided by the default client inventory.

It is important to note that, before you can add the information from MIF files to the SCCM database, you must first import the class information for them.  For more information on how to add a new inventory class, check out Technet article.  In a future post, we will explain how to create NOIDMIF and IDMIF files.

Ultimately, this technique will allow you to enhance the already robust capabilities of SCCM hardware inventory.  After utilizing the power of your newfound MIF knowledge, you will be wondering why you were ever “miffed” in the first place.

Jesse Walter is a protégé of Jason Rutherford and found true love in System Center.  He currently works in conjunction with Jason Rutherford and Rutherford, LLC to deliver seemingly impractical knowledge in practical ways.

System Center Service Manager (SCSM) Build Numbers

Found a very helpful link for Service Manger build numbers: Anders Asp Blog

Version (numeric) Version (name)
7.0.5826.0 SCSM 2010 RTM
7.0.5826.859 SCSM 2010 RTM with CU1 applied
7.0.5826.881 SCSM 2010 RTM with CU2 applied
7.0.5826.886 SCSM 2010 RTM with CU3 applied
7.0.6555.0 SCSM 2010 SP1
7.0.6555.101 SCSM 2010 SP1 with CU1 applied
7.0.6555.115 SCSM 2010 SP1 with CU2 applied
7.0.6555.128 SCSM 2010 SP1 with CU3 applied
7.5.1464.0 SCSM 2012 RC
7.5.1561.0 SCSM 2012 RTM
7.5.1561.106 SCSM 2012 UR 2
7.5.1561.112 SCSM 2012 UR 3
7.5.1561.116 SCSM 2012 UR 3 Re-Release
7.5.2905.0 SCSM 2012 SP1

Moving Service Manager’s 2010 SP1 Database – Summary

Recently I had an opportunity to upgrade a service manager 2010 sp1 environment to 2012 Sp1, easy right?…Right? Okay so there may be some challenges, but people like Travis Wright make the world of Service Manager easier. As many of us know the Service Manager Team Blog is a wealth of knowledge. One such nugget of information is the Moving the Service Manager Database Blog Post where much of the information I was looking for was found.

Here are the high-level steps…

1. Gather the Service Manager Management Group Name and SQL Server Database Server Name.
2. Stop Service Manager Services on the Management Servers and the Data Warehouse Server
3. Stop the Website and the Application Pool on the Server hosting the Self Service Portal
4. Back up the ServiceManager database on the old SQL Server.
5. Take the ServiceManager database offline on the old SQL Server.
6. Restore the ServiceManager database on the new SQL server.
7. Prepare the ServiceManager database on the new database server
8. Update management servers with the new database server name.
9. Back up the DWStagingandConfig database
10. Update the DWStagingandConfig database.
11. Start Service Manager Services on the Management Servers and Data Warehouse Server
12. Start the Website and Application Pool on the server hosting the Self Service Portal

In the coming weeks I’ll detail some of the gotcha’s with the move and the SCSM 2010 SP1 on SQL 2008 to SCSM 2012 SP1 on SQL 2008R2 SP1 upgrade process.