RefTool will be updated after 5 today. It contains the implementation of a “403 Forbidden” page for users who are signed in with SSO, but have not been given permission to use RefTool in Grouper.
Currently RefTool doesn’t tell the difference between users who are unauthenticated (not signed in) and unauthorized (signed in, but not permitted to access). The latter group will be thrown in redirect loop where their browser jumps back and forth between RefTool and SSO login.
After the update, these users will land on a 403 page. On this page, links to create tickets for OSU TeamDynamix Support and Service Desk will be shown, if they think they should be given access.
Does this affect me?
If you already have access to RefTool, you should not be affected by this update. However, if you lose permission for whatever reason and see the 403 page, follow the instructions.
RefTool will receive an update today at 5:15. The update restores searching for clients by first name and adds another alternative way to do so.
Two formats will be available to search for a client by first name:
FirstName [LastName] – where LastName is optional
FirstName; – first name, terminated with a semicolon
With this format, the user can omit the last name in the search query; however, the ending white space character (e.g. space) is required to differentiate between this and a username query. For example, to search for Jane, spell out “Jane” and a space. The LastName is received as “null”.
The FirstName [LastName] search format is error-prone because a single space is not always clear to the user. They may insert one by accident; on the other hand, if by intention, it is not immediately clear there is a space there either.
Introducing a new search format for just first name only. Instead of having to add a dangling space at the end of the first name, the user can also terminate the query with a semicolon (e.g. Jane;).
RefTool UI will interpret the search format of the user’s query as they type. Below is a video demonstration:
An update to SCCM sync will be pushed today after 7 PM. Here are the changes.
Setting Owning Customers
Before, SCCM sync set an asset’s owning customer by getting all users in TD and searching for a customer in that list. This was a very expensive task and it was restricted to after hours only.
Now, SCCM sync only gets single user if needed. As a result, SCCM sync can run from 7 AM and 7 PM everyday and update owning customers every time.
Matching SCCM and TDx Assets
Before, the script matched assets from SCCM and TDx by Resource ID (external ID) and serial number. This resulted in complications in cases of rebuilds, where the external ID must be updated.
Now, it does a single match by serial number and treats the external ID as simply another property of an asset to update.
Print CN Label Link
Lastly, the script now checks if an asset has the print CN label link set, in case it was not when the asset was created manually.
Before, KB documentation on asset sync was written in a single long article. Now, it is split into a short “parent” article that lists the scripts that make up asset sync and their schedules, and more specific articles for the individual scripts (which are linked in the parent article).
That’s all, folks! If you have questions or concerns, let me know.
RefTool will receive an update today at 7:15 PM that contains a couple of enhancements to the off-boarding script. Note that this tool currently is only for use by the Service Desk to on/off-board their student employees.
Reassigning Tickets and KB Articles
After the update, off-boarding an employee will:
Reassign the employee’s tickets to the Service Desk
Reassign KnowledgeBase articles they own to Kirsten Petersen.
RefTool will receive an update today after 7 PM. It adds a field named Duo Enforced to an account. Additionally, it adds the copy button to a few more fields.
A new field named Duo Enforced is added to RefTool. While Duo Mandatory is set by policy, Duo Enforced is set for special cases, such as grace period given to an account or a new account being given 7 days to sign up for Duo. Normally, Duo Enforced is set to “No”, unless the enforcement date is <7 days away, or it has passed.
Duo Enforced is the absolute date on which an account will be unusable without Duo.
To illustrate how Duo works, below are few screenshots with explanations:
The Copy Button
The copy button is currently used for an account’s Account Location, Distinguished Name, and Groups. It’ll be added to the following fields:
TDx Asset Sync is about to have a new script in place. It addresses a deficiency of SCCM asset sync script. In fact, SCCM asset sync associates an asset with the right department only when the AD OU needs to be updated. It does not associate the department when the AD OU matches, but has been manually assigned to another department.
For example, take the AD OU: CN/Office of Academic Achievement (OAA)/Computers. This belongs to Academic Achievement – Dept in TDx. If, in the future, there is some departmental change that requires the AD OU to be reassigned to another department, SCCM sync will not re-associate the asset to the new department, as long as the AD OUs from SCCM and TDx agree. Indeed, from testing we found hundreds of cases like this.
The AD OU – TDx Department Association Script aims to solve this. Once a week, it looks at every single SCCM asset and checks if its AD OU really belongs to the department assigned. If not, it will reassign the asset with the correct department.
Here are the technical considerations made when reassigning departments:
If the asset’s AD OU isn’t set, leave the department field unchanged.
If the asset’s AD OU cannot be associated to a department in TD, leave the department field unchanged.
There’s a department account named No department in TDx. Assets without associable AD OUs are assigned to this pseudo-department by SCCM Sync. Additionally, there are assets whose AD OUs are manually assigned to No department. We’ve decided to discontinue assigning assets to this department, both in the AD OU-Department sync and SCCM sync scripts.
Lastly, if the asset’s AD OU can matched to a real department, reassign it to that department.
From the number of assets changed in testing, we realized this is an expansive operation, particularly on the first run. However, we hope that departmental changes don’t happen often, so subsequent runs won’t change so many assets.
The association script will run every Sunday at midnight (0:00), starting this coming Sunday.