krypted.com

Tiny Deathstars of Foulness

I’ve worked with a lot of organizations switching between Mobile Device Management (MDM) solutions in my career. And I’ve seen the migration projects go both really, really well, and really, really poorly. In most cases, the migration is somewhat painful no matter what you do. But in this (my first) article on the JAMF blog, I try and organize my thoughts around a few things to look out for when migrating between MDMs/MAMs, and some context/experience around those.

https://www.jamfsoftware.com/blog/10-things-to-consider-when-switching-between-mobile-device-management-solutions/

Screen Shot 2016-06-23 at 11.45.32 AM

June 23rd, 2016

Posted In: Articles and Books, iPhone, JAMF, Mac OS X

Tags: , , , , , ,

Little article I/Bushel contributed to from Tech Republic covering considerations for small businesses looking to move to the Apple platform. It’s available at http://www.techrepublic.com/article/5-considerations-for-smbs-that-want-to-move-to-apple/#ftag=RSS56d97e7.

Screen Shot 2015-08-10 at 3.01.19 PM

August 9th, 2015

Posted In: Articles and Books, Interviewing, iPhone, Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , ,

Exchange is becoming more and more command line oriented. This includes the powershell options for managing Exchange once installed, but can also include the initial installation. To install Exchange from the command line, one must first install Exchange prerequisites, which are broken down per role that is being installed on Exchange. This can be done using the Add-WindowsFeature commandlet. To install the Windows requirements for Exchange for the Client Access, Hub Transport and Mailbox roles, use the following command:

Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy,Web-WMI -Restart

For the Edge Transport role, use:

Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Desktop-Experience -Restart

For the Unified Messaging role, use:

Add-WindowsFeature NET-Framework,RSAT-ADDS,ADLDS -Restart

After the server restarts, also configure NetTcpPortSharing:

Set-Service NetTcpPortSharing -StartupType Automatic

Once the required features are installed, you can then run the installer and extend the Active Directory schema to prepare for the new attributes required for the version of Exchange you’re installing (2010 for this article btw). To do so, use the setup.exe command. In this example command we’ll use the setup.exe located in c:ExchangeInstallers:

c:ExchangeInstallerssetup.exe /prepareschema

Once the Schema is ready, then prepare AD:

c:ExchangeInstallerssetup.exe /preparead

Then, prep the domain:

c:ExchangeInstallerssetup.exe /PrepareDomain

Note: For a full listing of what happens at the above stages of the installation, see TechNet 125224: http://technet.microsoft.com/en-us/library/bb125224(v=exchg.150).aspx

Once that’s done, I like to do a quick sync of AD from the control with my schema FSMO role:

repadmin /syncall

Then, for the easy part: install Exchange (in this case we’re installing Hub, CAS & Mailbox roles):

c:ExchangeInstallerssetup.exe /m:install /r:h,c,m

And voila, you’ve now got an Exchange Server. Since this is a Mailbox server, an empty information store is created and store.exe should be running. Use Get-Mailboxdatabase to verify:

Get-Mailboxdatabase -status

You can then move a database (e.g. to your SAN), since the default will be nested in the mdb folders in the Exchsrvr directory by using the move-DatabasePath cmdlet. Or use the move-storagegrouppath cmdlet to move the transaction logs.

Once the information store is back online and any logs have been moved, check the connectors in Exchange. Use get-sendconnector to see any outgoing connectors and get-receiveconnector to see any incoming connector information. You can also use get-exchangecertificate to check any certs on the host and get-routinggroupconnector to see any information about routing group connectivity.

June 11th, 2013

Posted In: Mass Deployment, Microsoft Exchange Server, Windows Server

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

When doing a data migration in OS X, you find that you often want to build a list of files on the source and the target media and then compare the two lists. When you do such a copy it’s important to verify that the data is all there. To find all the files on a drive, use the find command. If you’re in the working directory of the volume you’re transfering files from, the following command would show you all of the files on the volume:

find . -name "*"

To dump the contents to a file, use the > followed by the filename. So to list the contents of a volume into a file called source.txt, use:

find . -name "*" > source.txt

To do the same on the target volume, change the working directory to the target location and re-run, this time with a different name, like target.txt:

find . -name "*" > target.txt

To then compare the two, you could use diff:

diff source.txt target.txt

You could also use a third party tool to compare the files graphically. While there is a tool built into OS X for this, I like to use TextWrangler.

June 9th, 2013

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

Tags: , , , , , , ,

OS X Mountain Lion has a lot of scripts used for enabling services, setting states, changing hostnames and the like. Once upon a time there was a script for OS X Server called server setup. It was a beautiful but too simplistic kind of script. Today, much of that logic has been moved out into more granular scripts, kept in /Applications/Server.app/Contents/ServerRoot/System/Library/ServerSetup, used by the server to perform all kinds of tasks. These scripts are, like a lot of other things in Mountain Lion Server. Some of these include the configuration of amavisd, docecot and alerts. These scripts can also be used for migrating services and data, such as /Applications/Server.app/Contents/ServerRoot/System/Library/ServerSetup/MigrationExtras/30-ipfwmigrator. Sometimes the scripts are in bash, sometimes ruby, sometimes perl and other times even python.

Additionally, there’s a directory /Applications/Server.app/Contents/ServerRoot/System/Library/ServerSetup/MigrationExtras/ that is full of scripts for migrating services in OS X Server, helpful for even services that have been seemingly deprecated.

One of the things that can can be useful about the scripts scattered throughout the Server app is to learn how the developers of OS X Server intend for certain tasks to occur. One such example is /Applications/Server.app/Contents/ServerRoot/System/Library/ServerSetup/loggather.sh, used to grab logs. Here, you can learn the locations of certain logs as well as rudimentary stackshot commands. This is where I started calling stackshot before I did Server installs (or during), using the following command, which creates a custom text file containing :

/usr/libexec/stackshot -i -f /Library/Logs/ServerSetup_StackShot_KRYPTED.txt

This is also where I learned that I can tail /tmp/SetupLogs.tgz during some installs to be able to watch what’s going on during the installation process:

tail -f /tmp/SetupLogs.tgz

Looking At Each Service

This is also where I learned that Apple had put an Open Directory backup script in /Applications/Server.app/Contents/ServerRoot/usr/libexec/server_backup/opendirectorybackup (that still requires a password). But what I haven’t seen in all of these logs is bumping up the logging level for services before performing tasks, so that you can see a verbose output of what’s going on. To do this, it looks like we’re going service-by-service. So let’s look alphabetically, starting with Address Book:

sudo serveradmin settings addressbook:DefaultLogLevel = "warn"

This by defualt logs to /var/log/caldavd/error.log, which is built based on the following, which sets the base:

sudo serveradmin settings addressbook:LogRoot=/var/log/caldavd

And the following, which sets the file name in that directory:

sudo serveradmin settings addressbook:ErrorLogFile=error.log

You can change either by changing what comes after the = sign.

Next is afp. This service logs output to two places. The first is with errors to the service, using /Library/Logs/AppleFileService/AppleFileServiceError.log, the path designated in the following:

sudo serveradmin settings afp:errorLogPath = "/Library/Logs/AppleFileService/AppleFileServiceError.log"

The second location logs activities (open file, delete file, etc) rather than errors and is /Library/Logs/AppleFileService/AppleFileServiceAccess.log, defined using:

sudo serveradmin settings afp:activityLogPath = "/Library/Logs/AppleFileService/AppleFileServiceAccess.log"

The activity log is disabled by default and enabled using the command:

sudo serveradmin settings afp:activityLog = yes

The events that trigger log entries are in the afp:loggingAttributes array and are all enabled by default. There are no further controls for the verbosity of the afp logs.

The next service is calendar. Similar to address book, the caldav server uses DefaultLogLevel to set how much data gets placed into logs:

sudo serveradmin settings calendar:DefaultLogLevel = "warn"

This by defualt logs to /var/log/caldavd/error.log, which is built based on the following, which sets the base:

sudo serveradmin settings calendar:LogRoot=/var/log/caldavd

And the following, which sets the file name in that directory:

sudo serveradmin settings calendar:ErrorLogFile=error.log

You can changing either by changing what comes after the = sign.

Profile Manager is called devicemgr in the serveradmin interface and I’ve found no way to augment the logging levels. Nor does its migration script ( /Applications/Server.app/Contents/ServerRoot/System/Library/ServerSetup/MigrationExtras/80-devicemgrmigration.sh ) point to any increased logging during migration.

The dirserv (aka Open Directory) uses the slapconfig back-end, so I use slapconfig to increase logging:

sudo slapconfig -enableslapdlog

The DNS service uses named.conf, located in /etc to set log levels and has no serveradmin settings for doing so. Here, use the logging section and look for both the file setting (by default /Library/Logs/named.log) for where the log is stored as well as the severity setting, which can set the logging levels higher or lower.

By default Messages, or iChat Server, logs a lot. See the following for what is logged:

sudo serveradmin settings jabber:logLevel = "ALL"

Adding the -D option to the LaunchDaemon that invokes jabber will increase the logs. Logging long-term is handled in each of the xml files that make up the features of jabber. See the Logconfiguration section of the c2s file via:

cat /Applications/Server.app/Contents/ServerRoot/private/etc/jabberd/c2s.xml

The mail service has a number of options for logging, much of which has to do with the fact that it’s a patchy solution made up of postfix, etc. To see the virus database logging levels (which should usually be set to warn):

sudo serveradmin settings mail:postfix:virus_db_log_level

To see the spamassassin logging levels:

sudo serveradmin settings mail:postfix:spam_log_level

To see the actual postfix logging level:

sudo serveradmin settings mail:postfix:log_level

To enable timestamps on logs:

sudo serveradmin settings mail:imap:logtimestamps = yes

To set the dovecot logging:

sudo serveradmin settings mail:imap:log_level = "warn"

To set increased logging per function that dovecot performs, see the config files in /Applications/Server.app/Contents/ServerRoot/private/etc/dovecot/default/conf.d, each of which has a logging section to do so.

The NetBoot service is simple to configure logging for, simply set the netboot:logging_level to HIGH (by default it’s MEDIUM):

sudo serveradmin settings netboot:logging_level = "HIGH"

The Postgres service uses a log directory, configured with postgres:log_directory:

sudo serveradmin settings postgres:log_directory = "/Library/Logs/PostgreSQL"

The /private/etc/raddb/radiusd.conf has a section (log {}) dedicated to configuring how the radius service logs output.

The san service (Xsan) logs output per volume to both the System Log and volume-based log files, stored in /Library/Preferences/Xsan/data.

The smb service has a file /Library/Preferences/SystemConfiguration/com.apple.smb.server.plist
with a key for log level that can be used for more verbose output of the service.

The PPTP VPN service logs output to the file specified in vpn:Servers, configured with these:

sudo serveradmin settings vpn:Servers:com.apple.ppp.pptp:Server:LogFile = "/var/log/ppp/vpnd.log"
sudo serveradmin settings vpn:Servers:com.apple.ppp.pptp:PPP:LogFile = "/var/log/ppp/vpnd.log"
sudo serveradmin settings vpn:Servers:com.apple.ppp.l2tp:Server:LogFile = "/var/log/ppp/vpnd.log"
sudo serveradmin settings vpn:Servers:com.apple.ppp.l2tp:PPP:LogFile = "/var/log/ppp/vpnd.log"

By default, verbose logging is enabled, which you can see with:

sudo serveradmin settings vpn:Servers:com.apple.ppp.pptp:Server:VerboseLogging
sudo serveradmin settings vpn:Servers:com.apple.ppp.pptp:PPP:VerboseLogging
sudo serveradmin settings vpn:Servers:com.apple.ppp.l2tp:Server:VerboseLogging
sudo serveradmin settings vpn:Servers:com.apple.ppp.l2tp:PPP:VerboseLogging

The last service is web (Apache). The default access logs are per-site, with a key called customLogPath existing for each. The defaultSite uses the following for its logs:

sudo serveradmin settings web:defaultSite:customLogPath

Swap out the defaultSite with another site to see its log paths. There’s also a key for errorLogPath that shows errors. These are per-site so that administrators can provide access to logs for the owners of each site and not fear them having access to logs for other users. Global error logs are stored in /private/var/log/apache2/error_log as defined in /private/etc/apache2/httpd.conf. Find LogLevel in this file and set it to configure how in depth the logs will be, using debug for the most verbose and info, notice, warn, error, crit, alert, and emerg to get incrementally less information.

Additionally the log formats can be set in /private/etc/apache2/httpd.conf, allowing administrators to configure Mountain Lion Server’s built-in web service to conform to the standards of most modern web log analyzers.

Conclusion

Overall, there’s a lot of information in these logs and administrators can spend as much time reviewing logs as they want. But other than standard system logs, the output is typically configured on a service-by-service basis. Some services offer a lot of options and others offering only a few. Some services also offer options within the serveradmin environment while others use their traditional locations in their configuration files. I’ll end this with a warning. There can also be a lot of output in these logs. Therefore, if you set the logging facilities high, make sure to keep a watchful eye on the capacity of the location you’re writing logs out to. The reason I looked at paths to logs where applicable was because you might want to consider redirecting logs to an external volume when debugging so as not to fill up a boot volume and cause even more problems than what you’re likely parsing through logs looking to fix…

August 21st, 2012

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

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

If you have a web host that supports cPanel (a number do) then moving to Google Apps for Mail couldn’t be simpler. Just log in to your cPanel account and click on the Mail icon in the top left corner. From here, click on the last item in the list, Modify Mail Exchanger (MX Entry). Then click on change an MX Entry. In the Change MX for… drop down list, select the appropriate domain (if you only have one then there should be only the one to change and then enter aspmx.l.google.com in the to: field, clicking Change when you are done. According to the TTL value you will then need to wait for DNS replication to occur (it can take up 72 hours in some cases). In the meantime, mail should start to flow into your Google Apps mailboxes.

The next step is to actually migrate your mail. Assuming your administrator supports IMAP for your mailboxes this should be a fairly straight forward process. From the Google Apps administrative dashboard click on Advanced Tools in the blue toolbar. Then click on Migrate mail from mail server on the Advanced page and you will see a screen asking you to enter some information about your source IMAP server (the one that currently has all your data). In the Host field, type your domain name. cPanel uses Exim, which can work with the Dovecot setting in the Server software: field. Then enter 143 into the port number field (unless you use a different port) and if you use an IMAP prefix enter it now. You will also need to enter a maximum number of connections (according to how much data you want it to attempt to migrate at once).

Now you select the users whose data you will be moving. Click Next, and then choose whether to upload one or many accounts. Assuming one, you would simply enter the originating user name, target user name (in most cases these are the same) and then the password of the mailbox in cPanel. This means you need to know all your passwords, or reset them at the time of migration. Assuming many users, you would do the same thing in a csv file, creating a spreadsheet with username, source username, and source password as the columns and then populating the information from cPanel. Once done, save as csv and then use this screen to upload the file. Whichever option you chose, click on Start Migration to migrate the mail and then wait for the migration to complete.

If mail will not migrate using the stock example, searching Google for answers is a start but many may need to script solutions using the Google Apps email migration API.

POP mail will stay in the mailbox it was downloaded into. However, once you are done, POP users might end up redownloading mail. Contacts and calendars should be stored on your local devices and if you wish to migrate those you can (although this is going to be a more complicated process).

You will also need to change the local settings if you haven’t built a CNAME in DNS to point your old incoming and outgoing server addresses to the incoming addresses that Google uses. Client configuration should be a username of the full email address, the password you entered into your Google Apps domain dashboard and the incoming server name of imap.gmail.com. The outgoing mail server (SMTP) will be smtp.gmail.com and it will require authentication with the same information used for incoming (POP or IMAP) mail.

July 10th, 2009

Posted In: Mac OS X

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