Understanding Job Detection

When a print job arrives at MyQ, the server needs to match it to a user account. The value it uses for this match is extracted from the job itself, and must correspond to the username or an alias on the matching MyQ user account. Choosing the right detection method, and confirming that it works before configuring sync, helps prevent a common deployment problem: jobs arriving but not matching any user account.

Detection Methods

The main methods of identifying the user when a print job is received are:

• Job sender: MyQ reads the sender identity submitted with the print job. This is often the login name of the user on their workstation, typically sAMAccountName in Active Directory environments, though in some configurations it can be UPN. Use this method when the submitted job sender value matches the username or alias you synchronize into MyQ.

• From PJL: MyQ reads a field embedded in the print job by the driver, using a PJL command you define in the queue settings. Use this when the driver reliably embeds a consistent user identifier and you need more control over what value is extracted.

• Job name: MyQ reads the user identifier from the filename submitted with the job. This is used in specific application printing scenarios where the filename reliably encodes the sender.

Additional detection methods exist for edge cases. See the MyQ X Server guide for the full list.

How to Confirm Your Detection Method

It’s important to verify your detection method before you configure user synchronization. The easiest approach is to send a test job from a user account that does not yet exist in MyQ. MyQ will log the job as discarded with a message similar to this:

Job discarded. User "john.doe" not found.

The quoted value in this message is exactly what MyQ extracted and will try to match against. That is the value your synchronization job must place in the username or alias field.

In mixed-fleet environments with multiple driver types, test from each driver variant. Different drivers can embed different values in the same PJL field, and each combination may need its own queue configuration or alias mapping.

sAMAccountName, UPN, and Alias Strategy

For AD-synced users, MyQ always uses sAMAccountName as the username. There is no setting to change this. If your job detection returns UPN instead – common in environments where workstations are Entra-joined or where drivers are configured to use email-format identifiers – the match will fail unless UPN is also present as an alias on each user account.

The solution is to map userPrincipalName to the Alias field during LDAP synchronization. Once synced, MyQ will match jobs against both the username and all aliases, so UPN-identified jobs will authenticate correctly. The same approach can be used for other available and unique attributes, such as mailNickname, mail, or a custom attribute, if that is the identifier returned by job detection.

For Entra ID-synced users, UPN is always the username. If your print drivers send sAMAccountName-format identifiers, map onPremisesSamAccountName to the Alias field during Entra ID sync, where that attribute is available.

Mixed-Fleet Considerations

In environments with multiple print driver types – for example, a mix of Windows domain-joined workstations, macOS devices, and BYOD – it is common for different drivers to send different identifier formats. If different device or driver populations require different detection logic, use aliases to cover multiple identifier formats on each user account, or configure separate queues with the appropriate detection settings for each population.

Confirm the identifier sent by each driver type before finalizing the sync attribute mapping. Changing the detection method or alias configuration after users are already active in the system requires resyncing user accounts and may temporarily disrupt job authentication.