Get a reliable mapping of users-to-computers in Active Directory environment

Need to assign users to their workstations for purpose of assigning computer access for Remote Web Workplace in Small Business Server 2011. To do this, I need a reliable list of users' workstations. This would also be handy for discovery in new environments, so something automated or semi-automated would be preferred.

Couple of thoughts on how to achieve this:

• check/parse the security audit logs on the domain controller to match logon name to machine name in the logon events.

• write a logon script that echos logon name and hostname to a file on a network share.

• browse C$\Documents and Settings\ or c$\Users looking for most recently modified NTUser.dat

• Look in HK_USERS for SIDs and (possibly) find last logon time.

• Walk around and check each workstation name (boo! walking!)

Thinking the logon script might be the most hands-free and conclusive (will also show if users are on multiple machines and if so, would want to consider adding both machines to their profile).

Anything better?

NOTE: I should say that when setting up a new SBS server and using the http://connect method of joining to the domain, it will add the computer to the user's Remote Access tab > computer list. However, we're often doing migrations from existing DCs or SBS servers and this mapping is not always present or accurate.

Solution 1:

The login-script method is the least-effort method of getting what you're looking for.

I've done the first method, which involved a fair amount of scripting in PowerShell, and requires regular exports of the domain controller's security event-log. The advantage to that method is that it'll get everyone on everything which may not be the case for the login-script method; important when I had close to 3000 active computer-objects out there.

For SBS where you're going to be working with an order of magnitude (or two) fewer machines, the login-script method is probably your best bet. You may get one or two special snowflakes, but those should be easy to work around.