Skip to main content

Mastering ScrewDrivers Administration

Everything in ScrewDrivers Administration reduces to one sentence: objects are assigned to owners, and assignments flow down through inheritance. Once that model clicks, the whole console makes sense. This tutorial makes it click by having you build a small, realistic assignment structure and watch it resolve.

You'll need: your first deployment working (a print server or Direct IP printers, and at least two printers), Administration access, a test user account, and about 60 minutes.

Step 1: Learn the three panes​

Open ScrewDrivers Administration and orient yourself:

  • The icon bar switches which kind of object you're working with — printers, print servers, configuration settings, profiles.
  • The Objects pane (left) lists the objects of that kind.
  • The Information pane (right) shows the selected object's form, including its Assignments tab.

Click through two or three object types and watch the panes change. That's the entire navigation model — the Admin Console Overview is the full tour when you want it.

Checkpoint: you can find any object type in two clicks.

Step 2: Meet your owners​

Owners are who receives assignments: users, groups, organizational units, and clients. Open the owners view and find your Active Directory structure — ScrewDrivers reads your existing users, groups, and OUs, so you assign to the structure you already maintain. Find your test user and note which groups and OU contain them: those containers matter in Step 4.

Checkpoint: you can locate your test user and name at least one group or OU they belong to.

Step 3: Make a direct assignment​

Start with the simplest possible link:

  1. In the Objects pane, select one printer.
  2. Open its Assignments tab in the Information pane.
  3. Assign it directly to your test user, and save.

Log on as the test user in a session — the printer builds. One object, one owner, one assignment. Everything else is this, scaled up.

Checkpoint: your test user's session shows the directly assigned printer.

Step 4: Assign to a container and watch inheritance​

Direct per-user assignments don't scale — inheritance does:

  1. Assign your second printer to a group or OU that contains your test user.
  2. Log the test user on again: both printers build — one direct, one inherited from the container.

This is how real deployments work: assign to departments, floors, and sites, and users get the right printers by belonging to the right containers. When assignments overlap or need exceptions, the model has answers — deny and block assignments, and precedence rules — detailed in Managing Assignments and Entities and Inheritance.

Checkpoint: your test user gets a printer they were never directly assigned, and you can say why.

Step 5: Assign behavior, not just printers​

Here's the payoff of "everything is an object": settings assign exactly the same way. Session settings objects control how printers build and behave — creation, naming, defaults — and you assign them to owners just like printers. Select a configuration object, look at its Assignments tab, and recognize the identical pattern.

You won't configure them all today; the point is the shape. When you need specifics: Endpoint Printer Session Settings for the full reference, and printer profiles for captured driver settings — also just objects, also assigned to owners.

Checkpoint: you can explain what happens when a session settings object is assigned to an OU.

What you've learned​

Objects → owners → assignments → inheritance. You've built each link yourself, which means you can now predict what any user will get before they log on — and read any existing environment by walking its assignments.

Where next: Setting Up Your Print Server continues the path; Maps adds location-based assignment; Reports shows you what's actually being printed.