Hello all,

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.

Please read for some important notes about how our practice around Java install and troubleshooting has changed.

Short version: If you get a Java question, please check the KB before attempting to reinstall Java. Reinstalling Java may fix one application while breaking another.

As of last week, Sunapsis now requires 64-bit java. We pushed an update to Sunapsis users on 10/9 to give them 64-bit java, which caused some issues for people using either Nolij or Appworx.

The following article details the exact steps (in order) to get all three applications or any combination of them to work correctly: Java – Install Steps for Java with Sunapsis

Helpful Java documentation:

• Install Steps for Java with Sunapsis
• Install Java via NiNite
• Appworx – Java fails to launch (setting default file association for .jnlp files)
• Appworx – Can’t Login (edit java.security file to allow Appworx to work with Java versions beyond 8u191)
• Java Software InfoSheet (Internal)

Full details if you want ’em:

• Sunapsis requires 64-bit Java. The default file association for .jnlp files needs to be the 64-bit version.
• You can install both 32-bit Java and 64-bit Java and they can coexist; install the 32-bit version first.
• Internet Explorer is a 32-bit app and can only talk to the 32-bit version of Java. It just ignores the 64-bit version.
• Nolij works fine in Firefox and Chrome except that the “Scan to Nolij” and “File Browser” features will not be available. Internet Explorer with 32-bit Java is required if those features are needed.
• Appworx works with either the 32-bit Java or 64-bit Java. However, the java.security file needs to be edited manually if you use a version beyond 8u191.
• Installing via Ninite is recommended because we suppress Java updates that will likely break applications. However, 8u191 is not available on Ninite.