There’s a new JSS companion tool, called JSS MUT, which allows you to perform mass actions based on a CSV. Basically, set fields and enforce mobile device names (becoming a very common need out there). If you’re a JSS admin, it’s a nice tool, and a big should out to Michael Levenick for making it free!
Official website is at http://jssmut.weebly.com.
Hat tip to Trey Howell for clueing us in! 🙂
krypted July 18th, 2016
Posted In: JAMF
Apple School Manager is a portal used to create classes, import students, manage Managed Apple IDs, and link all these things together. You can use a Student Information System (SIS) to create these classes, import students, etc. But, only if you have a SIS with an API that Apple links to. If you don’t, you’ll need to import data using csv files. And you’ll need to import four csv files: Classes, Instructors, Staff, and of course Students.
Many schools will already have this data in Active Directory or another LDAP-based solution. Here, we’ll look at getting the information out of Active Directory and into csv. The LDIFDE utility exports and imports objects from and to Active Directory using the ldif format, which is kinda’ like csv when it gets really drunk and can’t stay on one line. Luckily, ldif can’t drive. Actually, each attribute/field is on a line (which allows for arrays) and an empty line starts the next record. Which can make for a pretty messy looking file the first time you look at one. The csvde command can be used to export data into the csv format instead. In it’s simplest form the ldifde command can be used to export Active Directory objects just using a -f option to specify the location (the working directory that we’re running the ldifde command from if using powershell to do so or remove .\ if using a standard command prompt):
ldifde -f .\ADExport.ldf
This exports all attributes of all objects, which overlap with many in a target Active Directory and so can’t be imported. Therefore, you have to limit the scope of what you’re exporting, which you can do in a few ways. The first is to only export a given OU (in this case called Students, but you could do one for Teachers, one for each grade, etc). To limit, you’ll define a dn with a -d flag followed by the actual dn of the OU you’re exporting and then you’d add a -p for subtree. In the following example we’ll export all of the objects from the sales OU to the StudentsOUExport.ldf file:
ldifde -d "OU=Students,DC=krypted,DC=local" -p subtree -f .\StudentsOUExport.ldf
Once you have the ldif file, you’ll want to convert it from ldif to csv. Some apps to do so:
Once you have the file in csv form, you can import it using the Apple School Manager web interface.
krypted April 22nd, 2016
You can now find an ldif to csv converter done in Swift on my Github account at krypted/swift-ldif-csv.
The project is pretty easy to use, simply define an input ldif file using the first positional parameter and then a csv using the -csv option. You can also use -a to define the attributes to migrate. Enjoy, fork, add, etc. For a quick download of the binary, click here.
krypted March 1st, 2016
The LDIFDE utility exports and imports objects from and to Active Directory using the ldif format, which is kinda’ like csv when it gets really drunk and can’t stay on one line. Luckily, ldif can’t drive. Actually, each attribute/field is on a line (which allows for arrays) and an empty line starts the next record. Which can make for a pretty messy looking file the first time you look at one. The csvde command can be used to export data into the csv format instead. In it’s simplest form the ldifde command can be used to export AD objects just using a -f option to specify the location (the working directory that we’re running the ldifde command from if using powershell to do so or remove .\ if using a standard command prompt):
ldifde -f .\ADExport.ldf
This exports all attributes of all objects, which overlap with many in a target Active Directory and so can’t be imported. Therefore, you have to limit the scope of what you’re exporting, which you can do in a few ways. The first is to only export a given OU. To limit, you’ll define a dn with a -d flag followed by the actual dn of the OU you’re exporting and then you’d add a -p for subtree. In the following example we’ll export all of the objects from the sales OU to the SalesOUExport.ldf file:
ldifde -d "OU=sales,DC=krypted,DC=local" -p subtree -f .\SalesOUExport.ldf
Restoring objects still results in an error that the server is “Unwilling To Perform” the import because “The modification was not permitted for security reasons.” Basically, this just means “hey I’m not going to import into some of the fields that I know I have to reserve for objects managed by the system, such as creation date (whencreated), last changed date (whenchanged), etc. So we can take some of these and omit them from our export. You can use ADMT or just look at an ldif or csv file to determine which attributes from the schema that you think need to be omitted, but at a minimum it should include objectguid, uSNCreated, uSNChanged, whencreated and when changed (and a lot of the Exchange attributes if you’ve extended the schema for your forest). To omit use the -o and enclose the omitted attributes in parenthesis. In the following example, we’ll export to the SalesOUExportO.ldf file, and add the -o flag to the previous command:
ldifde -d "OU=sales,DC=krypted,DC=local" -p subtree -o "objectguid,uSNCreated,uSNChanged,whencreated,whenchanged" -f .\SalesOUExportO.ldf
You can also omit using the -m flag, which includes only the essential attributes, so we’ll add that to the command as well:
ldifde -d "OU=sales,DC=krypted,DC=local" -p subtree -o "objectguid,uSNCreated,uSNChanged,whencreated,whenchanged" -m -f .\SalesOUExportO.ldf
Use the -l option to limit the attributes being exported to only those specified.
The -r option restricts the export to a given category or class. For example, if we only wanted to export users, we can restrict to objectClass-User
ldifde -d "OU=sales,DC=krypted,DC=local" -p subtree -r "(objectClass=user)" -o "objectguid,uSNCreated,uSNChanged,whencreated,whenchanged" -m -f .\SalesOUExportOM.ldf
Now I’m feeling like we have a good restricted set of data that we’re moving. Let’s go ahead and give importing a shot on a target server. To do so, we’ll just use -i to specify this is an import, followed by -k to say “don’t stop if you have a problem with just one record”, -f to define a file and -j to write a log. We’ll use the working directory for the file path and the log path, assuming this is being done by calling the .exe from within powershell:
ldifde -i -k -f .\SalesOUExportOM.ldf -j .\
Once complete, the exported objects should appear once you close and re-open Active Directory Users and Computers. You can also export one object, then programmatically create objects in an ldif file as needed by importing them into Active Directory using ldifde.
krypted February 27th, 2016
Posted In: Active Directory
DeployStudio has the ability to import a csv file that is populated with the MAC address and a few specific settings. This allows you to prepopulate the database with the names that you want each machine to have. If you purchase a lot of machines from Apple then you can get a list of MAC addresses, or, you can use a bar code scanner to scan them as you’re unboxing.
If you have a list of MAC addresses (en0), then you will need to format them in a very specific manner. Here, I have included a sample csv file with the data that goes into each field, which I have name DSImporter.csv.
Once you paste the data that you’d like into the csv, provide the computer names (these can be pasted or compiled using formulas). Once done, save and then open Deploy Studio Admin. From here, click on Computers and then (as you would with iTunes) click on the plus sign (+) and create a new computer list (this step is optional, but I prefer to always import into computer lists, just in case something goes wrong, especially with my first import). Once you have created the computer list, you should see a screen similar to the following.
Next, click on the Server menu and select Import.
You will then see your computers listed in the database and should see the names that you assigned them listed as well. You can now set a workflow item in DeployStudio for Reconfigure system with computers database content (shown below). This will set the name (and any other fields you decided to use) from the spreadsheet that you imported into the computer list.
Once you have your computers in a group, you can also set a default workflow for them for their first time imaging, by clicking on the name of the group and then clicking on the Automation tab at the bottom as you can see below.
Here, you will set the workflow to run and optionally set the computer to not have a default workflow moving forward or just be disabled so users can’t accidentally reimage their computers later.
If you don’t have the MAC addresses for your computers ahead of time, you can use the Hostname option instead.
This will enable you to enter the computer name that you would like to use moving forward into the DeployStudio Runtime at imaging and then have it stored in the DeployStudio database, where it can be used to build future workflows or even be exported and imported into the Open Directory computers.
Overall, the computers and groups in DeployStudio Admin can be used to design more and more complex imaging sequences and to provide much of the scripting logic that a number of organizations need. Beyond that, JAMF, FileWave and a few other solutions offer even more logic and even more features or a little shell scripting can take you a really long way.
krypted August 3rd, 2010
Whether you’re going from Open Directory to Active Directory or from Active Directory to Open Directory, chances are you’ll encounter csvde along the way. Csvde is installed on Windows Server and allows you to interface with Active Directory using csv files. cvsde can import files using the -i switch, followed by the -f switch to indicate the file that you are importing, followed by the path of the file. So if you save a file called toimport.csv to the root of your c drive temporarily you would use the following command to import the objects in the rows of the file:
csvde -i -f c:toimport.csv
Now, what’s that file need. At a minimum the file needs to indicate the objectClass for each user, the users sAMAccountName and the dn. So this file can be used to import a user called johndoe. But how to build a csv file like this from Open Directory? There are a number of ways, but here’s one way I’ve found works pretty well for me. First, let’s use dscl to dump a list of the long and short user names:
dscl /LDAPv3/127.0.0.1 -list /Users cn > import.txt
Now from Excel, click on File, Import and then select to import from a Text file, clicking Import. Then, browse to and double-click on your file, which if you used the above command would be called import.txt. Then, when it asks you for the Original data type, choose Fixed width. This will dump two columns. One with the short name, another with the name.
Now, download and open this spreadsheet I made for ya’ll. Paste the shortname column into the sAMAccountName column. Then paste the column with the full name into the D column, where John & Jane Doe are now. Then copy the user (objectClass) entry in column A to the number of rows you actually have (they will all be users) and then copy the CN= in column C to all of the rows you need. Then the , from column E and finally the OU/Search Base information for your Active Directory will need to replace that of mine. So if your Active Directory domain is called contoso.com (don’t laugh, I’ve seen it in production) and the ou you are going to use is Users then replace this text with OU=Users,DC=contoso,DC=com. Once you have all of the information filled in per row, notice that row G will automatically update. If you look at the formula, I’m just merging the contents of rows C-F. Copy the contents of rows 2 and 3 into the cells for column F until the end of your users.
Now you can take the information from column B and paste it into the toimport.csv and then take the information for row G and paste it into column C of the toimport.csv file (using Paste Special and pasting only the Value, NOT the formula). The objectClass will need to be filled in as user for each user as well (easily enough, this is user). Passwords aren’t to be imported, so using the 3 attributes from toimport.csv along with the command initially referenced earlier in this article give it a shot.
There are a number of other attributes that you will likely want to pull in and maybe augment as well. However, it’s late and I’ll have to talk about those later. In the meantime, do 1-2 users at a time until you feel confident to let csvde rip on all 10,000. I also strongly recommend bringing the initial import into a unique OU so that you can remove them all easily if things go wrong.
krypted August 19th, 2009