Blog Posts tagged with UWM Blog

Ask a question

Save Money by Metering Application Use


There's this consulting client I've worked with in the past. They're a big engineering firm, with nearly everyone working as a software developer. Being a for-profit company, cutting unnecessary costs where possible is always a good thing. But cutting costs for services that employees actually need is another thing entirely.

This firm had a problem recently where IT needed to cut annual software costs by a small percentage. Realizing that most software developers don't need Microsoft Project, they analyzed their software inventory to find people who probably didn't need the software.

They weren't prepared for the backlash that erupted a day later.

'Give us back this tool! Its removal prevents us from meeting our deadlines,' they cried. Removing Microsoft Project from even a small number of software developer computers quickly brought IT into the spotlight, 'Our developers are slipping schedule! We'll be late!'

It was software metering that ultimately vindicated IT's decision. With a cursory look through IT's software metering reports, the shouting managers slinked back to their offices realizing they were wrong.

They learned, much to their chagrin, that only three software developers on the entire project had even used Microsoft Project in over three months. With quantitative data, IT wins again.

Understanding Software Metering

Microsoft Windows is notoriously deficient when it comes to managing applications. Rapidly installing or uninstalling applications isn't easy without external tools. Inventorying those applications isn't a task that's particularly easy when you want to create nice reports across dozens or hundreds of machines.

Those limitations highlight why you won't find software metering tools as part of Windows' native operating system. Software metering represents a superset of information over just a basic software inventory report. While a software inventory report might tell you which software packages are installed, when they were installed, and by whom, software metering adds one additional piece of information: How much that software was actually used.

This is terrifically useful information when cutting software costs is important. If your head is on the chopping block for removing installed applications, you want quantitative data that proves your 'you haven't used it' assertions. With the right solution you could easily determine:

  • How many instances of an application are installed on computers, along with how many users actually ran the application.
  • Whether users are still using instances of an application that you no longer want to keep under software maintenance.
  • How many instances of the application are being used regularly and how many instances are only rarely being used, which can help reduce the number of licenses you're paying for.
  • Which dates, days, and times of day are instances of an application being used, to help determine if hosting (rather than directly installing) the application and using a concurrent licensing model might save costs.

Reports that contain the information above arm your IT organization with quantitative information. That information documents which users are actively using which applications. As with my engineering firm story, exactly that quantitative information is helpful when it comes time to start the uninstallations.

Creating Your Own Software Metering Solution

Any software metering solution starts first with a software inventory. Before such a solution can begin measuring use, that inventory is necessary to determine which applications to monitor.

It's also necessary because software metering isn't an activity you'll want to turn on for every application. Measuring the use of every application on a computer could have deleterious effects on its performance. More importantly, and as you'll discover in a minute, measuring everything just gives you too much information. Thus, most organizations limit it to just their apps of interest.

To accomplish this, most software metering solutions look at the instantiation of individual executables. For example, if you wanted to measure the use of Microsoft Word on a system, you would instruct your software metering solution to monitor the starting or stopping of the winword.exe process. Measuring only that piece of information it becomes possible (with some creative calculations) to determine how important an application is to its user.

Gathering this information doesn't necessarily require an external solution. You could collect it with Windows PowerShell alone. For example, the Get-Process cmdlet includes a property called StartTime that contains the last time the executable was instantiated. Running the following series of cmdlets will extract that information for winword.exe:

Get-Process | Where-Object { $ -eq 'winword' } | Select-Object StartTime

Figure 1 ' PowerShell Get-Process Command

The resulting output from this command might look like this:

3/27/2011 4:08:45 PM

There's a shorthand PowerShell notation you can use to gather StartTime from a process. The shorthand uses dotted notation rather than piping Get-Process to the Select-Object command. In doing so, it reports the StartTime information in a format that can be easily subtracted from the current time. First, the shorthand:

(Get-Process winword).StartTime

Using this syntax gives you a slightly different result, one that's more easily consumable by the step you're about to take. Use the Subtract method associated with the Get-Date cmdlet to subtract the current date/time from the StartTime of the winword process. That command looks like this:

(Get-Date).Subtract((Get-Process winword).StartTime)

The results from this command look something like this:

Days''''''''''''' : 0
Hours'''''''''''' : 0
Minutes'''''''''' : 51
Seconds'''''''''' : 57
Milliseconds''''' : 397
Ticks'''''''''''' : 31173970000
TotalDays'''''''' : 0.0360809837962963
TotalHours''''''' : 0.865943611111111
TotalMinutes''''' : 51.9566166666667
TotalSeconds''''' : 3117.397
TotalMilliseconds : 3117397

Notice how the current user has used Microsoft Word for 51 minutes during this period. That's useful information for metering their Microsoft Word over the long haul.

You can take this script one step even further and extend it to all the applications (or, technically, their processes) on a system. In this final version, I'll assume that you want just the number of minutes that each process has been running along with the process' name. Accomplishing this requires some extra effort with a ForEach loop and a couple of variables.

The syntax looks like this:

ForEach ($Proc in (Get-Process)) {
$ElapsedTime = (Get-Date).Subtract($Proc.StartTime) ;
Write-Host $Proc.Name,$ElapsedTime.Minutes }

Figure 2 ' PowerShell cmdlet to pull run time for all processes

While I've wrapped it for readability, this final command still functions within a single line. Being a single-line command makes it easy to schedule. The command uses ForEach to loop through all the results of Get-Process. Each resulting process gets its StartTime subtracted from the current time and recorded to the variable $ElapsedTime. Once measured, the final Write-Host is used to output the process name ($Proc.Name) and the elapsed time in minutes ($ElapsedTime.Minutes) to give you a list, a piece of which looks like this:

iexplore 13
inetinfo 14
iPodService 46
ipoint 16
iTunes 47
iTunesHelper 46

Figure 3 ' Results from process run time

The list goes is much larger than what you see here, obviously, because it represents every process currently running on the system. That list includes system processes like svchost, system, and others that you don't care about for metering. But it does give you a usable list of processes and their quantity of runtime.

Now, as you can surely see, this little command only highlights the current use of each process. And it only reports usage if those processes are actually up and running. Outputting its information requires running the script repeatedly and reporting each run's information to a file. Doing that is relatively easy.

The hard part is in consolidating the data, and turning that data into something that's useable. Once sent to that file, you're going to need some other kind of script that cleans up the data and generates a report of useful information. That part isn't something that's easy to discuss in a short article, and probably isn't something that you want to manage across dozens or hundreds of computers at once.

In the end, building a software metering solution is probably a task that's best left to the professionals. Companies that sell software metering solutions can easily add their functionality into whatever service they've already designed. Can you imagine how difficult it would be to manage installing your own PowerShell scripts all around your network? PowerShell itself isn't well designed to be constantly running against every computer, and managing such a system will only get more complex over time.

Integrating Metering with Whitelisting

Software metering is really only the start. There is another administrative function that goes hand-in-hand with it that you might like running inside your network. That function is application whitelisting. There are other articles on this website that discuss the activities associated with application whitelisting. For our purposes, know that whitelisting provides a mechanism to control which applications are allowed to run on your network.

Consider how metering and whitelisting could work well together. Once you've begun metering, you will immediately know which applications are not being used on your network. Since they are no longer being used, you can safely eliminate the costs associated with their licenses.

When you eliminate those costs and relinquish their licenses, you need some follow-on mechanism to ensure that users don't attempt to reinstall the application. A software whitelisting solution can be instructed to prevent the application from running on configured computers.

The all-or-nothing approach is admittedly relatively rare. Occurring much more often is when software metering discovers which users need the application most. In the Microsoft Project example, only three software developers were found to actually use the application. Thus, removing Microsoft Project from the other users makes budgetary sense. Restricting the application from the other users with a whitelisting solution then makes administrative sense. It prevents them from later using the application and invalidating your new software license terms.

Software Metering is a $mart Idea

Dollars are important to every business. So is software. But software that's been purchased and left unused is a waste of exactly those dollars. Implementing a solution that seeks out unused software so it can be removed is a smart move for any cost-cutting business. Take a look through the solutions on the market today to find one that meets your needs.

Who knows? You might find that the money you saved is well worth the cost of metering solution you purchased.

Be the first to comment

Sketching out a Self Service Password Solution

Video Transcript

Hi, this is Greg Shields. I want to spend a minute or two on the white board helping you sketch out a potential self service password solution. If you have read the article associated with this video then you already know the plight of Don the forgetful user. In that article I talk about Don the forgetful user who comes into work one day, tries to log on to his computer and realizes that he has forgotten his password. This can be a bad thing for Don because without that password, he can't get onto his computer. It bad thing for the help desk, because the only way for Don to get a new password is for Don to call the help desk, and then the help desk to change the password on the domain controller itself. This is not great, because there is a cost associated with calling into the help desk, and a time cost associated because you have to stop doing what you doing and help Don with his password'and read it very slowly to him back over the phone.

What might be a better solution is to instead create a solution where Don can help himself when he forgets his password. There are a couple of different ways you can go about doing this and there are couple of different solution approaches that are available.

One of the first ones I talk about in that article involves the use of a kiosk computer. A computer that just stays logged in all the time, because it is logged on with some generic user name and password. Don does not have to log on to the kiosk computer, he can go to a Web page and punch in credentials and answer some questions and then whenever he is done, have his password changed. Although the problem with kiosk computer is you have to have a computer that is logged on all the time in order to be able to use them. You have to have a separate computer waiting around for users to forget their password. Although kiosk computers may solve the immediate problem, they are not great for a long-term, self-service password solution. Let's go ahead and put that away.

There is another solution set out there as well. How easy would it be for Don to log on to his friends computer, say Mike's computer. From Mike's computer go to a Web site and answer those same question, but as you can imagine the same rules that don't like' logged on computers probably don't like Don logging on to Mikes computer. There is a problem there too. If Don is not anywhere near Mike or any of the other users in your organization, getting a hold of Mike's computer or any computer is going to be hard to help him change his password. Using somebody else's computer is not really a workable solution either.

What you want is some sort of agent that you can install on to Don's computer, like so.' That agent would go and manipulate the Control-Alt-Delete screen or some screen that Don can access, to allow him to go back and change his password. With an agent that has upgraded Don's computer in this way, Don could go right to his own computer and do some of those self-service things right there on his computer.

In order to be able to do this you cannot just go straight to the domain controller. Remember, Don has forgotten that password. There needs to be some secondary database of information that Don or I could use to verify that he is who he is. That database of information can be a series of questions that Don has asked and answered before he ever lost his password. Maybe his mother's maiden name, his first car, favorite movie, his dog's name, the combination of these questions and what their answers are helps me identify that Don is indeed Don and that will allow him to go and change his password. I need to have these secondary questions in place so that I can prove that Don is who he is.

As you can imagine, if I create this database of secondary questions I automatically create an element or database of personal information that I definitely do not want to get out. I definitely need to keep secured. So, when I am looking for a self service password solution, I want to look for one that includes some very strong controls so that this secondary information doesn't get out. Once I have that solution in place, the next time Don comes into work and forgets his password all he needs to do is go right to his own computer, answer a few questions, and he has a new password ready to go.

Be the first to comment

What is the Difference between a Group Policy and Preference

The Group Policy Preferences are the newest edition to the Group Policy family. And in newness comes some mysteries.

However, the Group Policy Preferences doesn't have to remain mysterious. In just a few short minutes I can help clear up some myths and expose some real facts about the Group Policy Preferences to help any Group Policy administrator out.

In my video, you'll learn the first 3 myths of Group Policy Preferences; including what it takes to make Group Policy Preferences "directives", which machines Group Policy Preferences work upon, and what the real difference between "Policy" and "Preference" really is.

You can also read my article, which explains the top 5 myths and facts about Group Policy Preferences.

Be the first to comment

How to Find & Use the Problem Steps Recorder

Video Transcript

Hi, this is Jeff Hicks. Today I want to show you a little known tool that ships with Windows 7.' It is also included in Windows Server 2008 R2.This is a nifty little tool that I think that you and your users can find helpful in documenting a problem so that you can better understand what the user is experiencing. This is called the Problem Steps Recorder. Unfortunately there is no menu choice, there is no icon, there is nothing that will give this to you right away. The best thing to do is to come to the Search box and type 'psr' and you will get this little dialog box.

I am going to pretend that I am a user here. I am going to start recording and this will now record everything that happens on my Desktop. So, it's recording and I am going to pretend I have a problem with Notepad. 'That whenever I run it I do not see it,' I do not know where it is, it is down here at the bottom, but I do not know why,' it always shows up as minimize, it is not to useful,' says the user. So they might then say, 'I clicked on that and I ran Notepad and it did not happen.' But if I go to the Command prompt, then it works and in fact they can come here and say, 'Add a comment,' and say, 'It works when I run Notepad from the shell.' They can highlight whatever they want. Something that indicates what I should pay attention to. Click OK and they can step through as much of the problem as they want. When they are done, we click on stop record. I am now prompted and I am now going to save this, a user might do this, on Network share \\cored01\HelpDesk, put it there and call this Client1-problem.' Let's do that.

Now if I look at this problem, and there is also a possibility here, you can come here and send email to recipient, this would then fire up the default mail client and automatically attach that file so you could email it off. I am just going through now and opening up files so we can see exactly what we were going to get from the Helpdesk side. It gets packaged as a Zip file, this is stored as an MHT file so when I launch this it opens up in Windows Explorer. There is the recorded steps, and now what I have here is a screen shot of everything that I did. There is also notes about every mouse click and key board movement. So I can walk through and see exactly what the user did to duplicate their problem. This becomes very useful when troubleshooting and trying to understand what the user did, what they clicked, what they didn't click, what keyboards entry they put in; all very useful stuff.

This is free. This the Problem Steps Recorder that is shipped with Windows 7. Again, to get to it you will need to come here and run 'psr'.' I hope you found that useful and you read the article and learn even more about this great little tool.'

Be the first to comment

The Right & Wrong Ways to Prevent Inappropriate App Execution

None of us love all applications equally. For one, there are those our users aren't supposed to be running: Streaming video. Elf bowling. Unapproved instant messaging. Try as you might, you'll never stop your users from getting to all of them.

These things kill productivity, hammer the network, and half the time seem packed with junkware, spyware, and who knows what else. And those are just the applications your users know they're not supposed to be running. There's also that whole class of 'quasi-business' applications that have an arguable business benefit ' but which your company hasn't paid for, isn't licensed to use, and doesn't want. Those can not only cause support issues, but outright financial damage if you're caught.

How can you stop them all?

It's tough. Windows' primary function, after all, is to run applications, and it does a pretty good job at it. Getting it to not run applications kind of goes against the grain. In Windows XP and Windows Server 2003, Microsoft introduced a technology called Software Restriction Policies (SRP), a part of Group Policy that was intended to keep unwanted applications from running.

With SRPs, you'd make a big list of all the applications you wanted to permit, and nothing else could execute. The technology more or less flopped. Oh, organizations definitely used it, and it works as advertised, but the process of assembling and maintaining that list of approved applications was incredibly complicated and time-consuming. Many, many organizations simply didn't have the time or resources, and so they gave SRP a miss.

That was 12 years ago. Hasn't anything better come along?

Introducing AppLocker

You've probably heard of AppLocker. It is a new feature of Windows 7 billed as the solution to SRP's tedious application whitelist maintenance. On paper, AppLocker scans your environment to find the installed apps and automatically constructs the whitelist for you. You can, of course, edit that to remove the already-installed applications that you don't want to permit, and you can maintain the list going forward.

So is AppLocker the answer?

Maybe. To be sure, AppLocker is still a complex piece of business, and it's far from perfect. To begin with, inventorying applications requires configuring client computers to run the new Application Identity Service, something that ships with Windows 7 but isn't enabled by default. This service is designed to read application rules from Group Policy, and then identify applications accordingly. In other words, this service basically makes AppLocker work.

Once enabled and running, the service reads application rules from Group Policy and evaluates every application that attempts to execute on the computer. If an application isn't permitted by your rules, then AppLocker prevents it from executing.

AppLocker logs verbose information to the Windows event log system, showing you which file was affected, whether it was blocked or allowed by a rule, the name of the rule, and so forth. On the face of it, this is pretty easy: Just get the service up and running on your client computers, something you can do with a Group Policy object (GPO) if you prefer. Configure rules in a GPO as well, and you're up and running.

AppLocker vs. SRP

First, a couple of differences between the old SRP and the new AppLocker, lest you think that AppLocker is just a quick way of generating SRP rules. AppLocker intends to deny applications by default, only allowing those that have a rule permitting them to run. AppLocker can also be run in audit-only mode, wherein it generates event log messages about the applications that are running. This is a key part of setting up AppLocker: By configuring those event logs to forward to a central computer, you can see which applications AppLocker might have blocked simply because you forgot to create a rule. By poring through the log entries (sounds fun, right?) you can ensure that you've accounted for every permitted application.

Generating the List

The problem with AppLocker all comes down to how you generate that whitelist. After all, AppLocker's roots are in SRP, which goes all the way back to Windows XP. Blocking applications isn't a new idea; what's supposedly new is the ease with which you can construct that whitelist.

Figure 1 - Applocker

The problem is that modern organizations have hundreds, if not thousands of applications. We're not talking about copies of Office, we're talking about the litany of line-of-business applications, tools, utilities, and other little pieces of software that people run. The sheer magnitude of an inventory project can often consume more time and more resources than you'll pay back with AppLocker, especially in smaller- and medium-sized businesses that don't have extra IT resources lounging around the datacenter.

AppLocker works by scanning one or more reference machines. The idea is that you take some machine that represents an 'allowed' set of applications. Most companies will start with a standard corporate desktop image that has all the standard corporate apps, and use that as their reference machine. AppLocker figures out what's on it, and generates rules to allow all of those applications. Easy.

Figure 2 ' Automatically Creating Whitelist Rules

Or is it? Do you ever install additional applications on top of that corporate image? Probably ' and AppLocker won't catch those right away. Do you have more than one corporate image? You're going to have to scan them all. And that's where AppLocker starts to get more complicated: Combining multiple rule sets, eliminating unwanted applications that are already out there, and so forth.

More complicated is the process of testing your AppLocker rules. Because the Application Identity service can be run in 'audit-only' mode, you can test your rules. However, the service only logs event entries to the local event log. That means you're going to need to configure multiple client computers (and servers, if you're using AppLocker to lock them down as well) to forward events to a central computer, and you're going to have to manually scan that computer to catch applications that would have been improperly blocked.

Figure 3 ' Enforce Rules vs. Audit Only

Ugly and time-consuming, you'll find yourself wishing for some kind of central consolidation and reporting functionality that Microsoft sadly hasn't included. Interestingly enough, Microsoft actually suggests you can also use Remote Desktop Services to remotely view events on other computers, but that's even more time-consuming.

AppLocker doesn't work well with the one-off exceptions that we all know are a way of life in IT. The CEO needs to run Elf Bowling? Creating that single exception isn't easy. You could remote into the CEO's machine (using Remote Desktop or Windows PowerShell) and configure an AppLocker rule as part of the machine's local policy.

If you're going to start using AppLocker, plan for those one-off exceptions to occur, and have a process for dealing with them (or very high-level support for not dealing with them). AppLocker also doesn't have a lot of flexibility: Once applied, it's applied until you change the rule set in its GPO(s). You can't have it stop working for certain time periods, although you can have it apply only to specific users or groups. There's no elegant way to temporarily allow a particular application. And AppLocker certainly isn't a licensing inventory or collection tool: It won't tell you how many people are running a given application, nor will it start blocking an application after a certain number of licenses are put into use.

Beyond SRP and AppLocker

If you've been using SRP, AppLocker is a huge step forward. If you haven't been using SRP, then AppLocker may not appeal to you either because it still comes with much of the same inflexibility. The good news is that, as an industry, we've never really relied on Microsoft to provide this kind of 'allowed application' functionality. Third party ISVs have always offered a far more robust set of capabilities.

While it's a great idea to block all but your specifically-allowed applications, most organizations aren't interested in doing so as a means of preventing malware. We've all got anti-malware software installed everywhere we want it, and it usually works just fine. What we need is to get a handle on the non-malware software that we simply don't wish to permit in our environments, and to get some control over software licensing.

Third-party software management applications tend to approach those goals similarly to AppLocker, starting with an automated inventory of applications. Rather than simply identifying applications by their publisher certificate or a file hash, true software management systems use massive databases that detect application fingerprints and create a more readable and effective inventory. With these solutions you'll know application names, versions, publishers, and so forth, so you can quickly spot which ones shouldn't be there ' and block them.

Unlike AppLocker, most third party solutions can tell you how many people are running each application. This knowledge is critical in the increasingly-challenging world of software licensing compliance. Some solutions even let you tell them how many copies you've paid for, and block allowed applications that are being used by too many people. In many cases, those solutions put users in a 'waiting list,' where they'll be notified when a license is available. Administrators will be notified that insufficient licenses are available, helping drive smarter software purchases in the future. You'll also be able to see when you have too many licenses for some product, and when upgrade time rolls around you can purchase fewer licenses and save some money.

These third-party solutions rarely require much more footprint than AppLocker itself. Usually there's a client-side service that you'll deploy, and some central server application and database. That central server is something AppLocker doesn't have or require (outside its Active Directory Group Policy roots), but it's the bit that gives you the central reporting and control AppLocker is missing.

Still, blocking unwanted applications is a project that requires ramp-up time. You're looking at an inventory process no matter which way you go, although with AppLocker you'll see more work in manual log reviewing than with dedicated third-party solutions. While AppLocker doesn't cost any more than your Windows 7 Enterprise or Ultimate licenses, it also doesn't provide the complete range of functionality that your organization may need. AppLocker may well be a fit for your needs, but before you turn it on and start generate rules in GPOs, take a few minutes to think about all the functionality you may need, and make sure that AppLocker is the right solution for your ongoing needs.

View comments (1)
Showing 1 - 5 of 97 results

Top Contributors

Talk About Troubleshooting