The approach to getting groups and permissions right looks quite different
depending on whether you're starting from scratch or inheriting an account that's
already in production. Both are very achievable — but they require different
sequencing and different levels of caution.
Path A: New account or greenfield deployment
This is the easier path, and the one where you have the most freedom to do things
properly. Resist the temptation to start deploying hosts before your structure is
ready. Two or three days of planning up front will save weeks of remediation later.
Design your Computer Group taxonomy on paper first
Map out your device types, locations, functions, or security tiers — whichever dimensions
you'll use to control access. Write down the group names you'll use and commit to a naming
convention before you create a single group in Central. Names like "EMEA-Kiosks-Retail" will
serve you far better than "Group1" when you're searching across 100+ groups six months
from now.
Create your User Groups next, before inviting a single user
Define your roles — "Help Desk Tier 1", "IT Admin", "Read-Only Auditor", "Regional Support –
EMEA" — and create the corresponding User Groups. When you create each User Group, take
the option to simultaneously create a matching Computer Group. Set the Computer Group and
feature permissions on each User Group now, while there are no users in them to be affected.
Create and assign your Host Preference Packages per device type
Build one HPP per device category before deploying any hosts. Assign each HPP to the
appropriate Computer Group. This way, every device that lands in a group automatically picks
up the correct security and consent settings — no manual configuration per machine needed.
Configure your deployment packages to target the right Computer Groups
When setting up deployment packages for mass installation, specify the destination Computer
Group explicitly. The Default Group should receive nothing — if a device ends up there, treat it
as a signal that your deployment process has a gap, not a temporary home.
Invite users into their groups — not directly into the account
When adding users, place them into the appropriate User Group immediately. If a user's role
doesn't fit any existing group, that's a signal to create the right group first rather than
assigning permissions individually as a shortcut.
Path B: Existing account that needs restructuring
This is the more common and more challenging situation. The account is live,
users are actively working, and you can't afford to disrupt access while you fix the
structure. The key principle here is: build the new structure in parallel before
dismantling the old one. Never remove existing access until the replacement is
confirmed working.
Before You Touch Anything: Do a Full Audit
Export or document your current state — which users exist, which groups they're
in, which individual permissions have been set, and which Computer Groups each
user can access. Central's Reports section can help here. This audit serves two
purposes: it's your rollback reference if something goes wrong, and it's the map
you'll use to understand what needs to change and in what order.
Identify and categorize your biggest structural problems first
There are typically three common anti-patterns in existing accounts: hosts piled in the Default Group with no meaningful grouping; users with permissions assigned individually rather than through groups; and over-privileged users with "All Computers" access who don't need it. Rank these by security risk and tackle the highest-risk issues first — over-privilege is usually more urgent than messy naming.
Create the target Computer Groups without moving anything yet
Build your new, properly named Computer Group structure alongside the existing one. Don't move any computers yet. This lets you assign HPPs to the new groups and verify the structure is correct before any live devices are affected.
Create the target User Groups and set their permissions
Build your role-based User Groups with the correct Computer Group and feature permissions. Leave existing users where they are for now. Once the new groups exist and are correctly configured, you can migrate users into them — but only after confirming the access scope is right for each role.
Migrate computers in batches, starting with the lowest-risk device types
Move hosts from the Default Group or legacy groups into the new structure in manageable batches — workstations first, then servers and critical devices last. Before moving any batch, map out who currently has access to those machines and confirm they'll have equivalent access in the destination group. Moving a computer changes which User Groups can see it, so communicate planned moves to your helpdesk in advance.
Migrate users into the new User Groups, then remove individual permissions
Once the Computer Group structure is stable, move users into their corresponding User Groups. Verify their access is correct — that they can reach what they should and can't reach what they shouldn't. Only once you've confirmed a user's group-based access is working correctly should you remove any individually-assigned permissions that are now redundant. Never remove individual permissions first.
Clean up the Default Group and legacy groups last
Once all hosts are in the right groups and all users are in the right User Groups, the Default Group should be empty (or contain only very recently deployed devices awaiting classification). Remove or archive legacy groups only after confirming nothing depends on them. An empty Default Group is a healthy signal that your deployment process is working correctly.
The Golden Rule for Existing Accounts
Access should never decrease as a side effect of restructuring — only as a
deliberate, reviewed decision. If a user loses access to a machine they need during
your restructuring work, you'll erode trust in the process and create pressure to
shortcut the remaining steps. Go slowly, communicate changes in advance, and
always verify before you remove.
Quick Reference: Do's and Don'ts
✓ Plan your Computer Group taxonomy before deploying any hosts — your naming
convention is your future navigation system.
✓ Create role-based User Groups and assign permissions to the group, not to
individuals. Keep individual user permissions empty where possible.
✓ Assign a Host Preference Package to every computer group at deployment to
ensure consistent security and remote control consent settings across hosts.
✓ Specify the destination Computer Group in your deployment package so new
hosts never accumulate in the Default Group.
✓ Regularly audit your Users list to remove terminated employees and contractors
— don't leave dormant accounts with live host access.
✓ Leverage Custom Fields to add metadata to hosts (owner, location, asset tag) —
at scale, searchability and filtering are essential.
✗ Don't give users access to "All Computers" unless absolutely necessary — scope
access to the specific computer groups they need.
✗ Don't move computers between groups without first mapping out which user
groups have access to the source and destination groups and communicating the
change.
✗ Don't assume a user who can see a host in Central can automatically access it —
Central account permissions and host-level UAC are separate layers.
✗ Don't confuse additive permissions for restricting access — if an individual user
has a permission, placing them in a group without it won't revoke it.
Helpful Resources from Central Support
Add a User Group in LogMeIn Central
Edit User Group Permission in LogMeIn Central
Manage Groups of Computers in LogMeIn Central
Define Which Computers a User Can Access
Control Who Can Access Your Host Computers (UAC)
Specific Permissions for Users and User Groups
Configure Host Preference Packages
