Tiny Deathstars of Foulness

When running mailbox exports, move requests, etc in Exchange 201x you might get an error. This is because the Management Role Assignments have changed ever so slightly. In order to provide an account the ability to do certain tasks, you can use the New-ManagementRoleAssignment powershell cmdlet to process a request. To do so, pick a user (in this case the username is kryptedadmin) using the -User option and choose roles to assign (in this case, mailbox, export and import) using the -Role option. The command then looks as follows:

New-ManagementRoleAssignment -Role "Mailbox Import Export" -User kryptedadmin

To see if your roles were properly applied:

Get-ManagementRoleAssignment -Role "Mailbox Import Export" | ft Identity

November 2nd, 2013

Posted In: Microsoft Exchange Server

Tags: , , , , , , , ,

Lion brings with it a few challenges for administrators. One such is migrating the wiki service into the new format. When doing an upgrade in place, the Wiki service is pretty straight forward to upgrade, but in many cases, due to aging hardware, wiki services are moving from an older computer to a newer computer. This can be done in one of two ways. The first is to “migrate” the data by copying the Collaboration folder onto the new system. The second is to “export” and “import” the data. I usually recommend doing a migrate where possible, so we’ll start with that method.

Note: Before getting started, make sure that the directory services side of things is good. If a user or group lookup for an object that owns, edits or has commented on a wiki fails then that wiki probably shouldn’t be migrated. Use the dscl or id commands to confirm that lookups are functioning as intended.

To migrate wikis from one server to another, first copy the Collaboration directory to the new server. In this example, the directory has been dropped onto the desktop of the currently logged in user. To migrate the data once copied, use the wikiadmin command, along with the migration option. The option requires the path to the Collaboration folder, defined with -r, as follows:

sudo wikiadmin migrate -r ~/Desktop/Collaboration

When moving wikis, you can take the opportunity to get rid of a few you don’t want (such as that test wiki from way back when). Or administrators may just choose to move a single wiki to a new server in order to split the load across multiple hosts. When doing so, use the same command as earlier, along with the name of each wiki that is being moved, along with the -g option. For example, if moving the Legal wiki:

sudo wikiadmin migrate -r ~/Desktop/Collaboration -g Legal

The second way of moving wikis around is to export and then import them. To do so, first export wikis on the old server, using the wikiadmin command along with the export option, which requires an –exportPath option and needs to be done, on a wiki-by-wiki basis. So to export that Legal wiki to a file called LegalWikiTMP on the desktop:

sudo wikiadmin export -g Legal --exportPath ~/Desktop/LegalWikiTMP

Next, copy the wiki to the new server and import it, using the import option along with –importPath to identify where the file being imported is located. Using the same location, the command would then be:

sudo wikiadmin import -g Legal --importPath ~/Desktop/LegalWikiTMP

Note: The ability to import a wiki also allows for an API of sorts, as you can programmatically create wikis from other sources. The ability to export also provides a way to move into another wiki tool if you happen to outgrow the options provided in OS X Server and need to move to something more robust.

There is another way to move wikis, using pg_dump, copying the data and then using pg_restore to import the data once you’ve created the tables.  This way is, in my opinion, the last resort if the standard wikiadmin commands aren’t working. In my experience, if I’m doing the migration this way then I’ve got other, bigger issues that I need to deal with as well.

These commands work best when the wiki service has been started so that the databases are fully built out. To start the wiki service from the command line, use the serveradmin command instead of the wikiadmin command. The serveradmin command is used with the start option and then wiki is used to indicate the wiki service, as follows:

sudo serveradmin start wiki

The service can also be stopped, swapping out the start option with a stop option:

sudo serveradmin stop wiki

Finally, in a few cases (this is the main reason I’m writing this article), the attachments to wikis don’t come over during a migration. To migrate the files that are used for QuickLook, downloading attachments, etc, use the serveradmin command to locate the directory that these objects are stored in:

sudo serveradmin settings wiki:FileDataPath

The output identifies the directory where these objects are stored. Placing the contents in the same relative path as they are to the output of the same command on the target server usually results in restoring them. Once moved, use the fixPermissions option to repair the permissions of any files from the source (if any changes to account IDs are encountered such as an export/import rather than an archive/restore in OD this can lead to odd issues:

sudo wikiadmin fixPermissions

Also use the rebuildSearchIndex option with the wikiadmin command to fix any indexing, once the permissions have been repaired:
sudo wikiadmin rebuildSearchIndex

And finally use resetQuicklooks to clear any cached Quicklook representations of objects that have been inserted into a wiki and might not display properly using Quicklook (you know you might need to do this if they look fine when downloaded but look bad with Quicklook even though QuickLook on the server can view the files just fine):

sudo wikiadmin resetQuicklooks

When done properly the migration can take awhile. Keep in mind that every tag, every article, every edit to every article and basically everything else is tracked inside the tables that you’re moving. While there might not be a ton of data in the Collaboration directory or in an export, all of the data needs to go to the right location. This can take a little time in environments that have a lot of articles, even if they’re really short articles…

July 11th, 2012

Posted In: Mac OS X Server

Tags: , , , , , , , , , , , , , ,

When you are configuring ExtremeZ-IP as a print server, you will need to set up and configure each printer. However, if you already have setup and configured printer queues for the Windows server, you can import existing queues into ExtremeZ-IP. This can be done programatically via the ExtremeZ-IP EZIPUTIL command line tool.

EZIPUTIL has a number of options, whereby the SERVER option is used to configure global settings for ExtremeZ-IP, VOLUME is used to create, edit and delete print queues and PRINT is used to manage shared print queues. Each of the options also has a number of switches for the feature(s) that are being managed. These are structured as standard switches that are used in Windows batch scripting. The /IMPORT switch can be used to import print queues. By defining the WINDOWS setting for the import, you will recreate all printer queues from Windows. This command would look like the following:


Once the command has been completed, you can then list printer queues using the /LIST switch:


Once you have created printer queues you will often end up needing to remove a queue or three. To remove a printer queue, you will use the /REMOVE switch along with a /NAME switch to specify the printer queue that you are removing. For example, to remove a queue called Accounting_499 you would use the following command:


The VOLUME option has a similar feature in the /REPLICATE_SMB switch, which allows you to replicate existing SMB/CIFS shares:


The /REMOVE switch can also be used with the VOLUME option. If you have created volumes you can also remove those from the command line. For example, to remove a shared volume called Accounting_Files, you would use the following command:


March 1st, 2011

Posted In: Mac OS X Server, Mass Deployment, Network Infrastructure, Windows Server

Tags: , , , , , , , ,

The netsh command can be used to manage network interfaces, control routing and one of the lesser-used features that I’ve seen are to import and export service settings with Windows Servers. This can be especially helpful if you need to normalize data for import into another Windows server or to be normalized for use with another server platform. To export your DHCP information, from a command prompt in Windows you would run the netsh command along with the service you are exporting settings for (WINS, DHCP, etc). After the service identifier you would indicate the action being performed (ie – import or export in this context), followed by a file to dump the data to and finally the subset of the data (we’ll use all for convenience sake and throw the data into an easily locatable place on the root of the C Drive, which you obviously need access to for the copy):

netsh dhcp server export C:dhcpsettings.txt all

Now that you have exported the data, you can copy it to your other Windows Server box and import using the exact same command (assuming the file lives in the same place) but swapping out your export for an import:

netsh dhcp server import C:dhcpsettings.txt all

DNS is a different beast given that there is a special dnscmd command for managing that service. To export your DNS information:

dnscmd ServerName /enumrecords zonename @ /type A /detail > c:mydnssettings.txt

Or in CSV:

dnscmd /enumrecords zonename @ /Type A /additional > c:mydnssettings.csv

One of the most used services for Windows servers though, is as a filer. File shares are stored in a registry key at HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesLanmanServerShares. You can browse here using regedt32 and then export the key. You would then use the Import option in the File menu (Windows 2003 uses Import whereas previous versions use Restore).

Note: Restoring this data will nuke and pave your existing shares on the box you’re running it on and in most cases you will need to restart appropriate services and/or the box to see the new settings.

August 10th, 2010

Posted In: Windows Server

Tags: , , , , , , ,

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.

Now browse to your csv file and then click on the Import button. When the import is complete you will see a screen informing you as such. Click on the Done button to complete the process.

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.

August 3rd, 2010

Posted In: Mac OS X, Mass Deployment

Tags: , , , , , , , , ,

Originally Posted to the 318 TechJournal:

318 has open sourced our mergeSafBookmarks python script. This tool can read in a pair of property lists and merge them into a single resultant bookmarks file for Safari. This takes a lot of the work out of pushing bookmarks to existing users as part of your deployment. You can find it here:

Note: The script also looks at existing bookmarks and doesn’t merge in duplicates.

December 22nd, 2009

Posted In: Mac OS X, Mass Deployment

Tags: , , , , ,

Recently, I did an article for where I explained that you can import a pkcs12 file into an 802.1x profile using networksetup. In that type of environment you would be leveraging TLS or TTLS with the Mac OS X client acting as the supplicant and the certificate required to establish authentication with the authenticator. So you need the certificate to get started, but how do you get the pkcs12 and dish it out to clients programatically?

We’re going to start out with a new keychain where we’ve imported the certificate into that keychain (or skip this step if you already have a p12 file). First, find the certificate and verify the name, as this is very important to networksetup. For this, I like to use the security command’s find-certificate option. Here we’re going to look for

security find-certificate -c

Now we’ll use the export verb of the security command to dump a .p12 file from the specially created keychain called 8021xkey,keychain to my desktop:

security export -k 8021xkey.keychain -t certs -f pkcs12 -o ~/Desktop/krypted.p12

When run you’ll be asked for a password to give the new p12 for decryption. Once we have the keychain it can easily be imported, as we will do from the desktop of a client system:

security import ~/Desktop/krypted.p12 -f pkcs12

Now we can use the p12 along with the -settlsidentityonsystemprofile or -settlsidentityonuserprofile. For example (using the default AirPort as the service and mysecretpassword as the password to decrypt the p12):

networksetup -settlsidentityonsystemprofile AirPort ~/Desktop/krypted.p12 mysecretpassword

Overall, at this point you can finally automate the process of setting up the 802.1x aspect of a deployment using a script or a package. Simply setup profiles at the GUI, import them into the new computer (assuming you have setup the service names before hand) and if need be import the certificate. Much testing required though…

September 9th, 2009

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , , , , ,

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/ -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 (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.

August 19th, 2009

Posted In: Mac OS X Server, Windows Server

Tags: , , , , , , , ,