Sunday, January 29, 2012

Lithnet.IdleLogoff – Log off users after periods of inactivity (with group policy support)

At the University I work for, we recently had an opportunity to redesign our student lab workstation environment from scratch. One of the seemingly simple requirements we had was to ensure that after a certain period of inactivity, users were logged off the machines. Sounds simple right?
Microsoft have a KB article that suggests a method to do this, but it’s not the best solution. It uses a screen saver as the timing mechanism, and starts a count-down timer in the background. If the user returns to the computer, they need to click a ‘cancel’ button that appears to stop them from being booted out. Not a very good user experience.
We couldn't find anything that did what we wanted. Something that would sit in the background, unobtrusively, and just log a user out after a predetermined amount of time. Oh, and it would be nice to control that amount of time if needed rather easily. Oh, and it would also be nice to disable the auto-logout completely if needed. And if its not asking too much, we want to be able to manage all this centrally.
So putting the screen saver idea aside, it sounded like it was time to develop a small app to do what we needed to. Lithnet.IdleLogoff was born…
image
As you can see, it is a really simple app, with only a few options for either enabling or disabling the agent and then setting the idle period. The app simply queries the relevant Windows API for the time since the user last interacted with the computer, and calls the logoff function after the specified period has elapsed. The power of this application comes from the fact you can either configure it locally, or manage it centrally via group policy.
image
The ADMX files are included in the installer. If you enable the setting, then the agent will be activated and log users off at the time you specify. If you disable the setting, then the agent will be disabled and will not log users off automatically. If you leave it as ‘not configured’, then whatever the local administrator of the PC has manually configured will take effect. Group policy will always override whatever you set locally.
To get started with the tool, install it and navigate to %ProgramFiles%\Lithnet\Lithnet.IdleLogoff, and run lithnet.idlelogoff.exe. This will launch the GUI to allow you to enable the agent, and configure the idle timeout. Alternatively, if you are configuring via group policy, then no further action is needed. Log off the workstation, and the next user to login will be subject to your idle logoff policy.
That’s it! No screen savers, message boxes, countdowns, beeps or other annoyances. Unobtrusive, simple, and centrally managed – my three requirements for anything that interacts with our managed desktops.

Download the latest version

Change log

Date Version Details
29/01/2012 1.0.4411 Initial release
25/11/2014 1.0.5442 Updated to provide support for user-based GPO settings
11/07/2016 1.1.6016 New combined installer for application and GPO extensions and built on .NET Framework 4.5.2

Lithnet.MoveUser - replacement for Microsoft's moveuser.exe and Win32_UserProfile.ChangeOwner


Lithnet.MoveUser is a command line tool that can be used to change the owner of a profile from one user to another. It is designed to be a replacement for Microsoft's moveuser.exe tool (used for Windows XP), originally included in the Windows Resource Kit, and the Win32_UserProfile.ChangeOwner WMI method, used for Windows Vista and above.

The Lithnet.MoveUser tool provides the same functionality as the other tools, but overcomes some of the shortcomings of the Microsoft provided toolsets. It does not require any scripting knowledge, provides a consistent experience across Windows XP, Vista, and Windows 7, and provides detailed logging of progress and any errors encountered.

The tool will perform the following tasks
  1. Change the owner of the profile to the destination user, and update associated permissions
  2. Add the destination user to the same local groups that the source user was a member of
  3. If the source account is a local account, then it can either be deleted, disabled, or left as-is after a successful migration. By default it is deleted
  4. The source and destination usernames can either be provided in standard username format (domain\username, computer\username) or as a SID
  5. The tool can also scan areas outside of a users profile for permissions assigned to the source user, and update them to apply to the destination user instead.
Ensure you have at least Microsoft .NET framework 3.5 installed, then download the tool and run the following command for help

lithnet.moveuser.exe /?


Examples:
The following examples take the profile for the local account for 'bob' and migrate it to bob's account in the lithnet domain
lithnet.moveuser.exe .\bob lithnet\bob
lithnet.moveuser.exe bob lithnet\bob
lithnet.moveuser.exe BOBSPC\bob lithnet\bob

The following example migrates the local profile for 'jane' and migrates it to the SID of jane's domain account (the workstation may not yet be joined to the new domain)

lithnet.moveuser.exe .\jane S-1-5-21-2656768339-1635643127-14959812366-1038

Other examples

lithnet.moveuser.exe .\dave lithnet\davidm /replace
lithnet.moveuser.exe john lithnet\johnsmith /postmoveaction:keep
lithnet.moveuser.exe S-1-5-21-2656768339-1635643127-14959812366-3442 S-1-5-21-2
56768339-1635643127-14959812366-1030
lithnet.moveuser.exe otherdomain\john lithnet\john
lithnet.moveuser.exe lithnet\john .\john
Download Latest Version

Change log

Date Version Details
29/1/2012 1.0.4411 Initial release

Building an enterprise-ready replacement for MoveUser.exe and Win32_UserProfile.ChangeOwner

Moveuser.exe

Back in the early days of Windows XP, Microsoft released a tool for changing the owner of a user profile from one user to another. Moveuser.exe came in the Windows Resource Kit, and for the most part did an OK job.

The most common use was for taking profiles that belonged to local user accounts, and attaching them to domain user accounts. It could also be used for migrating profiles from one domain to another, although the Active Directory Migration Tool (ADMT) was more commonly used for this task.

The command line was simple enough;

moveuser.exe oldusername newusername

It took usernames in format of COMPUTER\username or DOMAIN\username. Once of the other nice things about moveuser.exe is that it also copied a user’s group membership on the local machine.

Moveuser wasn't without its problems;

  1. Error messages returned by the tool were generally unhelpful. A single Win32 error code can't tell you a lot about why a profile migration might have failed.
  2. Moveuser.exe was limited to using account names that the local PC could resolve. This was problematic when trying to move a user profile from one domain user to another, without having a trust relationship between the two domains.

However, support for moveuser.exe was dropped in Windows Vista, and replaced by a WMI method on the Win32_UserProfile class called 'ChangeOwner'.

Win32_UserProfile.ChangeOwner


ChangeOwner was a little trickier to use. Firstly, you have to delve into the world of WMI and scripting. While not too difficult, it requires knowledge of WMI and an appropriate scripting language such as VBScript.

Secondly, the method requires you to pass it the SID of the user accounts involved in the migration. You need to be able to translate your account names in advance into the user's corresponding SIDs. This adds quite a bit more scripting complexity. However, the benefit of this approach, is that if you know the SIDs in advance, the local computer does not need to know about the source or destination username at all.

However, the ChangeOwner function dropped support for copying the user's local group membership, so once again, we are having to do more scripting to perform this function.

Then, as mentioned previously, Microsoft have the ADMT tool, that can be used to perform profile migrations within domains. However, there is no support for migrating workgroup-based computers and local accounts.

So the situation we are left with, is having three completely different tools, each with their own capabilities and caveats, to use across different operating system generations.

ADWMT was born

At the organisation I work for, we just moved 16,000 users from a Novell-based workgroup to an Active Directory domain. I needed a solution that I could reliably push out to all supported operating systems, join all workgroup-based computers to the AD, as well as consolidate 9 other AD domains into a new central domain. None of these tools were going to cut it! We had to come up with our own solution.

After several months of solid development and testing, we had a tool that would reliably migrate the whole fleet of workstations, without user interaction, and provide us with detailed management reporting. The Active Directory Workstation Migration Tool (ADWMT) was born. It was capable of;

  1. Joining workstations to the domain
  2. Automatically mapping local user accounts to user accounts in the domain
  3. Automatically mapping user accounts in one domain to user accounts in another domain
  4. Migrating local user profiles to domain accounts
  5. Migrating profiles from one domain to accounts in another domain
  6. Keeping local group membership in tact
  7. Working without any user interaction
  8. Providing detailed reporting
  9. Running on Windows XP, Vista and 7
  10. Performing migrations over a wired or wireless network
  11. Auto-repairing network configuration issues (especially where no lanmanserver or lanmanworkstation installed)
  12. Running custom scripts at any stage throughout the migration
  13. Being able to be run by a user without admin rights, and auto-elevate using a predefined list of admin accounts

If you are interested in using the ADWMT tool for use in your organisation, send me an email to discuss licensing options.

Lithnet.MoveUser

I decided to extract the profile migration engine from ADWMT, and make it available for anyone to use. It is designed as a replacement for moveuser.exe and ChangeOwner, combining the benefits of both tools, with some additional enhancements.

  1. A single command line tool, that takes either usernames (as moveuser.exe does), or SIDs (as ChangeOwner does)
  2. Runs on XP, Vista, and Windows 7
  3. Provides detailed logging and reporting
The tool requires .NET framework 3.5 to be installed. See this post for full details including a download link.

My first update in a while…

 

OK so I have been off the air for quite some time. My apologies to those that I have not been able to get back to with questions/comments recently.

I’ve been out of the UC space for quite some time, so have not had a chance to continue my previous work with OCS and Exchange UM. I hope the information I have provided has helped some people, but I likely won’t be updating the content or adding new UC material in the near future.

My current focus has been in the desktop management space, looking at tools and technologies used to manage large (10,000+) fleets of Windows workstations for an increasingly mobile workforce. I’ll be writing about my experiences and lessons learnt in this space, and providing tools I have written to hopefully help others in their endeavours.

Stay tuned for future posts!