The ribbon at the top of the interface can be expanded or collapsed by clicking on the collapse arrow, by using the keyboard shortcut Ctrl and F1, or by double-clicking on the currently selected tab.
When collapsed, the ribbon will only show the tab names, and will display in full temporarily after clicking on a tab name until you select a ribbon item or move the focus back to the main interface.
If your ribbon bar has disappeared completely (not even the tab names are visible), you'll need to reset your interface back to its default settings. This can be done by either reinstalling the program, or by deleting the following registry key (and subkeys):
HKEY_CURRENT_USER\Software\Javelina Software\ADreporter\BCGWorkspace
Common Properties are special names that map to Active Directory attributes, and are usually displayed when the corresponding attribute name is not necessarily obvious. For example, as you might expect, the Common Property First Name maps to the attribute givenName. Some other attributes, like userAccountControl, are bitfield attributes which contain multiple settings. For these attributes, we've created Common Properties that help expose these individual settings, making it easier to set them or report on them. The Disabled Common Property, which reflects one of the userAccountControl bits, is an example of this type of Common Property.
The following table contains a list of the most common Common Properties, along with the attributes they map to, if any. Common Properties that differ only in capitalization or spacing from the corresponding attribute have been excluded.
Common Property | LDAP Attribute | Notes |
---|---|---|
Business Phone | telephoneNumber | |
City | l | |
Canonical Name | The Canonical Name is a reformatting of the Distinguished Name. For example, mydomain.net\Users\John Doe . |
|
Container | The container common property retrieves the Distinguished Name of the parent object in Active Directory. | |
Country | co | |
Email Address | ||
Expiration Date | accountExpires | |
Fax | facsimileTelephoneNumber | |
First Name | givenName | |
Full Name | cn | |
Home Folder Drive | homeDrive | |
Home Folder Path | homeDirectory | |
Last Name | sn | |
Logon Name | userPrincipalName | |
Logon Script | scriptPath | |
Middle Name | initials | |
Mobile Phone | mobile | |
Netbios Name | sAMAccountName | |
Notes | info | |
Office | physicalDeliveryOfficeName | |
Phone | telephoneNumber | |
PO Box | postOfficeBox | |
State | st | |
Street | streetAddress | Note that this common property does not map to the attribute "street". See What's the difference between "Street"...? |
Zip Code | postalCode |
Some attributes in Active Directory refer to other Active Directory objects. Attributes of these referenced objects are known as Child Attributes in ADreporter.
For example, the Member Names property of a group contains the Distinguished Name of all of the group's members. If we wanted to report on the members' email addresses, we can do that by first selecting the Member Names property to retrieve the group's members, then selecting the "Child attribute" Email Address as shown in the image below from the built-in group report "Member Information":
You'll notice a field called Object Type in the screenshot above. This field allows us to choose which set of attributes we want to see in the lists below. For instance, say we want to create a report showing the direct members of all of the groups in the directory, and in the case where the group member is another group, show that group's member count. Like in the screenshot above, we'd select Member Names as the base attribute, but when we try to select the "Member Count" child attribute, it isn't in the list because "Member Count" is not a valid attribute for User objects. Change the Object Type to "Group", and ADreporter will now give the option to show the member's "Member Count" property. This "Member Count" child attribute will simply return nothing when run against one of the group members that isn't also a group.
ADreporter provides the ability to report on several Office 365 attributes for your users including Last Sync Time, Office 365 Logon Name, Sign-In Blocked, Licenses, and Usage Locations. See the complete list of Office 365 attributes that can be reported on by adding a new column to a report. The Office 365 Common Properties have names starting with "Office 365".
In addition to Active Directory attributes, the Import Wizard allows you to map columns to Common Properties. Common Properties are aliases we've created that map to Active Directory attributes, and are usually displayed when the corresponding attribute name is not necessarily obvious. See What is a Common Property? for more information.
Although we've made an effort to ensure that most Common Property names are straightforward, the "Street" Common Property is a little unusual. It does not map to the street Active Directory attribute as you might expect it to, but rather to the streetAddress attribute. This was done to better mimic Microsoft's user interfaces, which often refer to the field as "Street", even though they are setting the "streetAddress" attribute behind the scenes. This decision had the unfortunate side effect of creating confusion with the Active Directory attribute "street", which is also a valid attribute for User objects, though it is not regularly used.
To make a long description short, if you want to report on the "Street" field as it appears in property sheets in Active Directory Users and Computers, use "Street" (uppercase) or "streetAddress". If you want to retrieve the rarely-used attribute "street", map your column to "street" (lowercase).
ADreporter filters are used to limit the objects within a particular scope. Filters consist of a set of conditions, which are grouped into Match All or Match Any groups to provide support for complex queries.
Above the filter field, there is a row of buttons. These buttons are used to modify the filter by adding conditions or groups, modifying filter items, deleting items, or shifting them around. Below is a description of each of the buttons and their purpose:
Button | Description |
---|---|
Add Condition | Add a condition to the selected Match Any or Match All. |
Add Match Any Group | Add a nested Match Any group to the currently selected group. This button will add the new nested group and launch the Add Condition dialog to add a condition to the newly created group. |
Add Match All Group | Add a nested Match All group to the currently selected group. This button will add the new nested group and launch the Add Condition dialog to add a condition to the newly created group. |
Edit | If a condition is selected, the Edit button will launch the Modify Condition dialog to edit it. If a group is selected, the Edit button will ask if you'd like to change the group's type between Match All and Match Any. |
Delete | Removes the currently selected condition or group from the filter. |
Move Up | Moves the selected item up within its parent Match All or Match Any group. |
Move Down | Moves the selected item down within its parent Match All or Match Any group. |
Sure. ADreporter filters are very powerful, but unfortunately there's always a trade-off between power and complexity. It can be helpful to sit down ahead of time and figure out the exact conditions you're trying to match, and how those conditions are linked together.
Match Any groups are used when an object only has to match one condition from a group in order to pass the test. The default Inactive Users filter is a good example of a Match Any group. When trying to match a user against this filter, the first thing we do is look at the Disabled state of the user. If the user is Disabled, the Match Any group is immediately satisfied, and we don't need to look at any of the other conditions.
Match All groups are used when an object has to match all of the conditions from a group in order to pass the test. In the filter above, we are matching on Users named Joe in the state of California. If we had used a Match Any group here instead, the filter would have picked up everyone in California, as well as all the Joes from other states. But that's not what we want; we want only the Joes in California. Therefore, we use Match All.
If you were paying attention to the last 2 examples, this one should be pretty straightforward. Like Example 2, it will show all of the Joes in California. But there's a new item at the bottom of the Match All group, a Match Any group. This Match Any group is the same as the group in Example 1, which shows Inactive Users. So, this filter shows the inactive users named Joe in California.
If a user fails to meet any of the 3 items under the Match All group, he will not match. That is, if the user is not named Joe, or if the user is not in California, or if the User is not Inactive (aka "if the User is Active").
What if I switch the groups around?
Interesting question. This new filter will match users named Joe, and users in California, and users that meet all 5 conditions in the Match All group. If you look closely however, you'll see that it's not possible to meet all 5 conditions in the Match All group, because that would require the user's Last Logon attribute to be empty and equal to 0 at the same time. So, we can ignore the entire Match All group. That means the filter will simply match all users named Joe, and all users in California.
Simply select the report from the Report Tree, then click the Run button in the ribbon. A screen will appear asking you to verify the scope and output settings for the report. Click the
Run Now button at the bottom of this screen and the report will run.
For example, if you'd like to run a report to find out email address information for your users, you'll want to make sure the Users category is selected in the ribbon, then choose the Email Address Information report from the list. Verify that the report shows the information you need in the Preview pane, then click the Run button in the ribbon to launch the report.
Yes, absolutely. Reports in ADreporter are categorized by object type. In order to create a new report, you first must choose the type of object you want to appear on the report and select the corresponding category in the ribbon.
Once you've done that, simply click on the New Report button in the ribbon, and follow the instructions in the New Report Wizard to create the report. When you've completed the wizard, your new report will appear in the Report Tree.
For more information about the New Report Wizard, click here.
The Report Scope property in the Scope group of the Report Properties pane controls the containers on which the report runs. Simply click the the button to launch the Report Scope dialog.
The top of this dialog allows you to specify the objects on which the report will run. Use the Select button to add a container to the grid. If you are running an AD Object Report or a File Report, you can also select individual objects to add to the scope by clicking on the down arrow on the Select button and choosing the second option instead. To import objects from a file into the grid, select Import From File, however, if you need the report to use the objects written in the file at runtime, you may set an import file. This can be useful to run a report on the output of another report. You can adjust the scope level of each container you add to the report by selecting the item and using the Scope Level button to switch between Entire Subtree, This Object and Its Children, or This Object Only.
Scope Level | Description |
---|---|
Entire Subtree | All objects in the container's sub-tree will be added to the report. |
This Object and Its Children | This object and its immediate children will be added to the report. |
This Object Only | This object will be added to the report. |
In the example below, we are setting the report scope for our Inactive Users report. The report is set to be run on two containers, Javelina Software\Engineering
and Javelina Software\Sales
. Any users found within the Javelina Software\Engineering\Maryland
container will be added to the report, because the scope level for the Engineering container is set to Entire Subtree. On the other hand, users found within the Javelina Software\Sales\Maryland
container will not be added to the report because the Sales container is only set to a scope level of This Object and Its Children.
Sure is! The Report Scope property in the Scope group of the Report Properties pane is used to limit the objects that appear on the report. Click the the button on the Report Scope property to launch the Report Scope dialog.
The bottom grid of this dialog controls the report filter. Filters are used to specify a series of conditions that must be met in order for the object to be included on the report. For more information about how to create filters, see How do I create a filter?
Instead of creating a custom filter for your report, you may load the filter and scope from a collection. This is done by clicking the load a collection dropdown on the top right of the dialog, and selecting the collection to copy the settings from. Builtin and custom collections that match the current report type will be shown.
When you're finished creating your report filter, click the Ok button to save the filter to the Report Properties.
![]() |
Yes. The Output group of the Report Properties pane gives you options for saving the report output to a file, or sending an email when the report is complete. Use the Use Global Output setting if you have report output settings specified in the Options dialog (available via the To have the report save itself to a file each time it runs, enable the Save Report property by checking the checkbox as shown in the image to the left. The type of file must also be specified by clicking the If you want to have ADreporter automatically send an email when the report is complete, you'll need to check the Send Email checkbox and set up the email properties. If you are saving the Report File or Output File, you can choose to attach these files to the email with the corresponding checkboxes. Fill in the recipient fields as you would in any other email. You can enter multiple email addresses by separating them with a semicolon. The Comments: field can be used to set the body of the email. Once that information is entered and the report is saved, an email will be sent to the recipients each time the report is run. |
Scheduled Tasks in ADreporter are more robust compared to their equivalent in previous versions of our software. Whereas in prior versions, a scheduled task could be linked to only one report, tasks in ADreporter can run multiple reports.
Furthermore, you can add actions to a task outside of running an ADreporter report. These actions, available from the button, include things like running an external program or sending an email. For more information about these kinds of actions, see Task Action Dialog.
Click the button to the right of the Output field in the Task Settings to modify the output settings for the task. This dialog will provide settings for saving the task output to a file or sending an email once the task is complete.
Newly created tasks (or copied tasks) in ADreporter default to running under the local System account. This account should be sufficient for actions like sending an email, or executing an external program. However, if you are trying to run an ADreporter tool or report from your task, you will likely need to set the task to run as a user with more permission.
Also, it's possible that the task is running, but that an error occurred while running a tool or report task action. Verify that the task output is not reporting any errors, and if you are running a tool or report, check to see if the action-specific output files are created. These output files, if they exist, should help guide you to the problem. For more information about task output files, see How can I save output from my task?
Finally, you can try running the task directly from the Run Now button on the ribbon to verify that there are no issues with your task configuration.