Tag Archives: caldav

Mac OS X Mac OS X Server Mac Security Mass Deployment

Configure The Calendar Service In Mac OS X Yosemite Server

Configuring Calendar Server in Yosemite Server is a fairly simple and straight forward process. The Calendar Server is a CalDAV Server, leveraging HTTP and HTTPS, running on ports 8008 and 8443 respectively. To enable the Calendar service in Yosemite Server, open the Server application and click on Calendar in the SERVICES section of the sidebar.

Calendar1

Once open, click on Edit to enable email notifications of invitations in the Calendar Server. Provide the email address and then click on the Next button.

Calendar2

At the Configure Server Email Address screen, provide the type of incoming mail service in use, provide the address of the mail server and then the port number used, if not a standard port for HTTPS-based IMAP (or POP if you’d prefer), the user name and the valid password for the account. Then click on the Next button.

Calendar3

At the outgoing mail server screen, provide the Outgoing Mail Server address, the port, whether or not SSL is in use (it should be if possible), the password protocol, the user name and the password. Then click on the Next button.

Calendar4

At the Mail Account Summary screen, review the settings and if correct, click Finish. Back at the service configuration screen, click on the plus sign (“+”) and provide a type of location, an address, a delegate, a name for the location, whether or not invitations to the resource are accepted and then enter the account name for any accounts that can manage the location’s calendar (they will auto-complete, so there’s no need to remember users and groups exactly). Click Done to complete the setup. Use the Resource setting in type to configure a resource instead of a location. The two are the same, except the Type field.

Calendar5

There are a number of settings that can also be configured. But those are exposed only at the command line. To configure them, open the command line and then review the list of Calendar service settings using the list option of the serveradmin command:

sudo serveradmin settings calendar

There are a number of settings for the Calendar service, including the following:

calendar:SSLCertificate = "/etc/certificates/Server Fallback SSL Certificate.11C002258ECABBFB37846C9B0CEA59391D4759AD.cert.pem"
calendar:EnableCalDAV = yes
calendar:Notifications:Services:APNS:CardDAV:CertificatePath = "/Library/Server/Calendar and Contacts/Config/Certificates/apns:com.apple.contact.cert.pem"
calendar:Notifications:Services:APNS:CardDAV:PrivateKeyPath = "/Library/Server/Calendar and Contacts/Config/Certificates/apns:com.apple.contact.key.pem"
calendar:Notifications:Services:APNS:CardDAV:AuthorityChainPath = "/Library/Server/Calendar and Contacts/Config/Certificates/apns:com.apple.contact.chain.pem"
calendar:Notifications:Services:APNS:CalDAV:CertificatePath = "/Library/Server/Calendar and Contacts/Config/Certificates/apns:com.apple.calendar.cert.pem"
calendar:Notifications:Services:APNS:CalDAV:PrivateKeyPath = "/Library/Server/Calendar and Contacts/Config/Certificates/apns:com.apple.calendar.key.pem"
calendar:Notifications:Services:APNS:CalDAV:AuthorityChainPath = "/Library/Server/Calendar and Contacts/Config/Certificates/apns:com.apple.calendar.chain.pem"
calendar:Notifications:Services:APNS:Enabled = yes
calendar:SSLAuthorityChain = "/etc/certificates/Server Fallback SSL Certificate.11C002258ECABBFB37846C9B0CEA59391D4759AD.chain.pem"
calendar:DefaultLogLevel = "warn"
calendar:Authentication:Digest:Enabled = yes
calendar:Authentication:Digest:AllowedOverWireUnencrypted = yes
calendar:Authentication:Kerberos:Enabled = yes
calendar:Authentication:Kerberos:AllowedOverWireUnencrypted = yes
calendar:Authentication:Wiki:Enabled = yes
calendar:Authentication:Basic:Enabled = yes
calendar:Authentication:Basic:AllowedOverWireUnencrypted = no
calendar:ServerHostName = "mavserver.takecontrolbooks.com"
calendar:Scheduling:iMIP:Sending:UseSSL = yes
calendar:Scheduling:iMIP:Sending:Server = "mail.krypted.com"
calendar:Scheduling:iMIP:Sending:Address = "com.apple.calendarserver@calendar.krypted.com"
calendar:Scheduling:iMIP:Sending:Username = "admin"
calendar:Scheduling:iMIP:Sending:Password = "Mitroae123"
calendar:Scheduling:iMIP:Sending:Port = 465
calendar:Scheduling:iMIP:Enabled = yes
calendar:Scheduling:iMIP:Receiving:UseSSL = yes
calendar:Scheduling:iMIP:Receiving:Server = "mail.krypted.com"
calendar:Scheduling:iMIP:Receiving:Type = "imap"
calendar:Scheduling:iMIP:Receiving:Username = "krypted"
calendar:Scheduling:iMIP:Receiving:Password = "Mitroae123"
calendar:Scheduling:iMIP:Receiving:Port = 993
calendar:DataRoot = "/Library/Server/Calendar and Contacts/Data"
calendar:EnableCardDAV = no
calendar:SSLPort = 8443
calendar:LogLevels = _empty_dictionary
calendar:DirectoryAddressBook:params:queryUserRecords = no
calendar:DirectoryAddressBook:params:queryPeopleRecords = no
calendar:SSLPrivateKey = "/etc/certificates/Server Fallback SSL Certificate.11C002258ECABBFB37846C9B0CEA59391D4759AD.key.pem"
calendar:EnableSSL = yes
calendar:RedirectHTTPToHTTPS = yes
calendar:EnableAPNS = yes
calendar:EnableSearchAddressBook = no
calendar:HTTPPort = 8008

One of the more common settings to configure is the port number that CalDAV runs on. To configure HTTP:

sudo serveradmin settings calendar:HTTPPort = 8008

For HTTPS:

sudo serveradmin settings calendar:SSLPort = 8443

You can then start the service using the start option:

sudo serveradmin start calendar

Or to stop it:

sudo serveradmin stop calendar

Or to get the status:

sudo serveradmin fullstatus calendar

Full status indicates that the three services are running:

calendar:readWriteSettingsVersion = 1
calendar:setStateVersion = 1
calendar:state = "RUNNING"
calendar:contactsState = "RUNNING"
calendar:calendarState = "RUNNING"

Once the Calendar server is configured, use the Calendar application to communicate with the server. Open the Calendar application and click on the Calendar menu and select Preferences. From the Preferences screen, click on Accounts to bring up a list of accounts. Here, click on the plus sign (“+”) to bring up the “Add an Account” screen.

Calendar6

At the “Add an Account” screen, select Add CalDAV Account.

Calendar7

CalDAV from the Account Type menu and then enter the User Name and password configured on the server, and add the address of the server if you don’t have any service records pointing to the server. The User Name is usually the name provided in Server app, followed by @ and then the address of the server.

Calendar8

Once the server is configured it appears in the list of accounts in the sidebar of the Calendar app. Create calendars in the account and then to share a calendar, right-click on the calendar and click on Share Calendar…

Calendar9

At the Share Calendar screen, provide the name the calendar should appear as to others and click on the plus sign (“+”) and enter any accounts to delegate administration to.

Calendar10

Back at the Calendar Settings screen, use the settings to configure Availability and refresh rate of calendars, as seen above. Click on Server Settings to assign custom port numbers.

Calendar11

Click on the Delegation tab to view any accounts you’ve been given access to.

Calendar12

Use the Edit button to configure who has delegated access to calendars, as opposed to configuring subscriptions.

Overall, the Calendar service in Yosemite Server is one of the easiest to configure. Most of the work goes into settings configured on client systems. This, as with Exchange, dedistributes administration, often making administration more complicated than with many other tools. But that’s a good thing; no one wants to access other peoples accounts, for calendars or mail for that matter, without those users knowing that it was done, as will happen when resetting passwords…

Mac OS X Mac OS X Server Mac Security Mass Deployment

Configure The Contacts Server In OS X Yosemite Server

Yosemite has an application called Contacts. Yosemite Server has a service called Contacts. While the names might imply differently, surprisingly the two are designed to work with one another. The Contacts service is based on CardDAV, a protocol for storing contact information on the web, retrievable and digestible by client computers. However, there is a layer of Postgres-based obfuscation between the Contacts service and CalDAV. The Contacts service is also a conduit with which to read information from LDAP and display that information in the Contacts client, which is in a way similar to how the Global Address List (GAL) works in Microsoft Exchange.

I know I’ve said this about other services in OS X Server, but the Contacts service couldn’t be easier to configure. First, you should be running Open Directory and you should also have configured Apple Push Notifications. To setup Push Notifications, have an Apple ID handy and click on the Contacts entry in the SERVICES section of Server app.

Contacts1

Click the Edit button to configure the Apple Push Notification settings for the computer. When prompted, click on Enable Push Notifications.

Contacts2

If prompted, provide the username and password for the Apple ID and then click on Finish.
To enable the Contacts service, open the Server app and then click on Contacts in the SERVICES section of the List Pane. From here, use the “Include directory contacts in search” checkbox to publish LDAP contacts through the service, or leave this option unchecked and click on the ON button to enable the service.

Contacts3

The Contacts service then starts and once complete, a green light appears beside the Contacts entry in the List Pane. To configure a client open the Contacts application on a client computer and use the Preferences entry in the Contacts menu to bring up the Preferences screen. From here, click the Accounts menu and then click on Add Accounts.

Contacts4

At the Add Account screen, click Add Other Account…

Contacts5

Click Add a CardDAV account.

Contacts6

At the “Add a CardDAV Account” screen, select CardDAV from the Account type field and then provide a valid username from the users configured in Server app as well as the password for that user and the name or IP address of the server. Then click on the Create button.

Contacts7

When the account is finished creating click on the Server Settings tab if a custom port is required. Otherwise, close the Preferences/Accounts screen and then view the list of Contacts. Click on the name of the server in the Contacts sidebar list. There won’t be any contacts yet, so click on the plus sign to verify you have write access to the server.
Next, let’s get access to the LDAP-based contacts. To do so, bring up the Add Account screen again and this time select LDAP from the Account Type field.

Contacts8

Provide the name or IP address of the server and then the port that LDAP contacts are available over (the defaults, 389 and 636 with SSL are more than likely the settings that you’ll use. Then click on the Continue button.

At the Account Settings screen, provide the name that will appear in the Contacts app for the account in the Description field and then enter the search base in the Search base field. To determine the search base, use the serveradmin command. The following command will output the search base:

sudo serveradmin settings dirserv:LDAPSettings:LDAPSearchBase

Then set Authentication to simple and provide the username and password to access the server for the account you are configuring. The list then appears.

The default port for the Contacts service is 8443, as seen earlier in the configuration of the client. To customize the port, use the serveradmin command to set addressbook settings for BindSSLPorts to edit the initial array entry, as follows:

sudo serveradmin settings addressbook:BindSSLPorts:_array_index:0 = 8443

The default location for the files used by the Contacts service is in the /Library/Server/Calendar and Contacts directory. To change that to a folder called /Volumes/Pegasys/CardDAV, use the following command:

sudo serveradmin settings addressbook:ServerRoot = "/Volumes/Pegasys/CardDAV"

The service is then stopped with the serveradmin command:

sudo serveradmin stop addressbook

And started with the serveradmin command:

sudo serveradmin start addressbook

And whether the service is running, along with the paths to the logs can be obtained using the fullstatus command with serveradmin:

sudo serveradmin fullstatus addressbook

The output of which should be as follows:

addressbook:setStateVersion = 1
addressbook:logPaths:LogFile = "/var/log/caldavd/access.log"
addressbook:logPaths:ErrorLog = "/var/log/caldavd/error.log"
addressbook:state = "RUNNING"
addressbook:servicePortsAreRestricted = "NO"
addressbook:servicePortsRestrictionInfo = _empty_array
addressbook:readWriteSettingsVersion = 1

If you’re easily amused, run the serveradmin settings for calendar and compare them to the serveradmin settings for addressbook:

sudo serveradmin settings calendar

By default, the addressbook:MaxAllowedInstances is 3000. Let’s change it for calendar:

sudo serveradmin serveradmin settings calendar:MaxAllowedInstances = 3001

And then let’s see what it is in addressbook:

serveradmin settings addressbook:MaxAllowedInstances

Mac OS X Server

Configure the Calendar Service in Mavericks Server

Configuring Calendar Server in Mavericks Server (OS X Server 3) is a fairly simple and straight forward process. The Calendar Server is a CalDAV Server, leveraging HTTP and HTTPS, running on ports 8008 and 8443 respectively. To enable the Calendar service in Mavericks Server, open the Server application and click on Calendar in the SERVICES section of the sidebar.

Screen Shot 2013-10-06 at 8.02.02 PMOnce open, click on Edit to enable email notifications of invitations in the Calendar Server. Provide the email address and then click on the Next button.

Screen Shot 2013-10-06 at 8.02.28 PM

At the Configure Server Email Address screen, provide the type of incoming mail service in use, provide the address of the mail server and then the port number used, if not a standard port for HTTPS-based IMAP (or POP if you’d prefer), the user name and the valid password for the account. Then click on the Next button.

Screen Shot 2013-10-06 at 8.03.02 PMAt the outgoing mail server screen, provide the Outgoing Mail Server address, the port, whether or not SSL is in use (it should be if possible), the password protocol, the user name and the password. Then click on the Next button.

Screen Shot 2013-10-06 at 8.03.42 PMAt the Mail Account Summary screen, review the settings and if correct, click Finish. Back at the service configuration screen, click on the plus sign (“+”) and provide a type of location, a name for the location, whether or not invitations to the resource are accepted and then enter the account name for any accounts that can manage the location’s calendar (they will auto-complete, so there’s no need to remember users and groups exactly). Click Done to complete the setup. Use the Resource setting in type to configure a resource instead of a location. The two are the same, except the Type field.

Screen Shot 2013-10-06 at 8.04.36 PMThere are a number of settings that can also be configured. But those are exposed only at the command line. To configure them, open the command line and then review the list of Calendar service settings using the list option of the serveradmin command:

sudo serveradmin settings calendar

There are a number of settings for the Calendar service, including the following:

calendar:SSLCertificate = "/etc/certificates/mavserver.pretendco.lan.10E6CDF9F6E84992B97360B6EE7BA159684DCB75.cert.pem"
calendar:EnableCalDAV = no
calendar:Notifications:Services:APNS:CalDAV:CertificatePath = "/Library/Server/Calendar and Contacts/Config/Certificates/apns:com.apple.calendar.cert.pem"
calendar:Notifications:Services:APNS:CalDAV:PrivateKeyPath = "/Library/Server/Calendar and Contacts/Config/Certificates/apns:com.apple.calendar.key.pem"
calendar:Notifications:Services:APNS:CalDAV:AuthorityChainPath = "/Library/Server/Calendar and Contacts/Config/Certificates/apns:com.apple.calendar.chain.pem"
calendar:Notifications:Services:APNS:CardDAV:CertificatePath = "/Library/Server/Calendar and Contacts/Config/Certificates/apns:com.apple.contact.cert.pem"
calendar:Notifications:Services:APNS:CardDAV:PrivateKeyPath = "/Library/Server/Calendar and Contacts/Config/Certificates/apns:com.apple.contact.key.pem"
calendar:Notifications:Services:APNS:CardDAV:AuthorityChainPath = "/Library/Server/Calendar and Contacts/Config/Certificates/apns:com.apple.contact.chain.pem"
calendar:Notifications:Services:APNS:Enabled = yes
calendar:EnableAPNS = yes
calendar:DefaultLogLevel = "warn"
calendar:Authentication:Digest:Enabled = yes
calendar:Authentication:Digest:AllowedOverWireUnencrypted = yes
calendar:Authentication:Kerberos:Enabled = yes
calendar:Authentication:Kerberos:AllowedOverWireUnencrypted = yes
calendar:Authentication:Wiki:Enabled = yes
calendar:Authentication:Basic:Enabled = yes
calendar:Authentication:Basic:AllowedOverWireUnencrypted = no
calendar:DataRoot = "/Library/Server/Calendar and Contacts/Data"
calendar:Scheduling:iMIP:Sending:Server = "mavserver.pretendco.lan"
calendar:Scheduling:iMIP:Sending:UseSSL = yes
calendar:Scheduling:iMIP:Sending:Username = "com.apple.calendarserver"
calendar:Scheduling:iMIP:Sending:Address = "com.apple.calendarserver@mavserver.pretendco.lan"
calendar:Scheduling:iMIP:Sending:Password = "JAdMTWx9Bh9JaaGm"
calendar:Scheduling:iMIP:Sending:Port = 587
calendar:Scheduling:iMIP:Enabled = yes
calendar:Scheduling:iMIP:Receiving:Server = "mavserver.pretendco.lan"
calendar:Scheduling:iMIP:Receiving:UseSSL = yes
calendar:Scheduling:iMIP:Receiving:Username = "com.apple.calendarserver"
calendar:Scheduling:iMIP:Receiving:Type = "imap"
calendar:Scheduling:iMIP:Receiving:Password = "JAdMTWx9Bh9JaaGm"
calendar:Scheduling:iMIP:Receiving:Port = 993
calendar:ServerHostName = "mavserver.pretendco.lan"
calendar:EnableCardDAV = yes
calendar:SSLPort = 8443
calendar:LogLevels = _empty_dictionary
calendar:DirectoryAddressBook:params:queryPeopleRecords = no
calendar:DirectoryAddressBook:params:queryUserRecords = no
calendar:SSLPrivateKey = "/etc/certificates/mavserver.pretendco.lan.10E6CDF9F6E84992B97360B6EE7BA159684DCB75.key.pem"
calendar:EnableSSL = yes
calendar:RedirectHTTPToHTTPS = yes
calendar:SSLAuthorityChain = "/etc/certificates/mavserver.pretendco.lan.10E6CDF9F6E84992B97360B6EE7BA159684DCB75.chain.pem"
calendar:EnableSearchAddressBook = no
calendar:HTTPPort = 8008

One of the more common settings to configure is the port number that CalDAV runs on. To configure HTTP:

sudo serveradmin settings calendar:HTTPPort = 8008

For HTTPS:

sudo serveradmin settings calendar:SSLPort = 8443

You can then start the service using the start option:

sudo serveradmin start calendar

Or to stop it:

sudo serveradmin stop calendar

Or to get the status:

sudo serveradmin fullstatus calendar

Full status indicates that the three services are running:

calendar:readWriteSettingsVersion = 1
calendar:setStateVersion = 1
calendar:state = "RUNNING"
calendar:contactsState = "RUNNING"
calendar:calendarState = "RUNNING"

Once the Calendar server is configured, use the Calendar application to communicate with the server. Open the Calendar application and click on the Calendar menu and select Preferences. From the Preferences screen, click on Accounts to bring up a list of accounts. Here, click on the plus sign (“+”) to bring up the “Add an Account” screen.

Screen Shot 2013-10-06 at 8.08.17 PMAt the “Add an Account” screen, select Add CalDAV Account.

Screen Shot 2013-10-06 at 8.09.18 PMCalDAV from the Account Type menu and then enter the User Name and password configured on the server, and add the address of the server if you don’t have any service records pointing to the server. The User Name is usually the name provided in Server app, followed by @ and then the address of the server.

Screen Shot 2013-10-06 at 8.10.47 PMOnce the server is configured it appears in the list of accounts in the sidebar of the Calendar app. Create calendars in the account and then to share a calendar, right-click on the calendar and click on Share Calendar…

 

Screen Shot 2013-10-06 at 8.12.55 PM

At the Share Calendar screen, provide the name the calendar should appear as to others and click on the plus sign (“+”) and enter any accounts to delegate administration to.

Screen Shot 2013-10-06 at 8.15.52 PMBack at the Calendar Settings screen, use the settings to configure Availability and refresh rate of calendars, as seen above. Click on Server Settings to assign custom port numbers.

Screen Shot 2013-10-06 at 8.14.20 PM

Click on the Delegation tab to view any accounts you’ve been given access to.

Screen Shot 2013-10-06 at 8.14.49 PM

Use the Edit button to configure who has delegated access to calendars, as opposed to configuring subscriptions.

Overall, the Calendar service in Mavericks Server is one of the easiest to configure. Most of the work goes into settings configured on client systems. This, as with Exchange, dedistributes administration, often making administration more complicated than with many other tools. But that’s a good thing; no one wants to access other peoples accounts, for calendars or mail for that matter, without those users knowing that it was done, as will happen when resetting passwords…

Mac OS X Server

Configure The Contacts Service In Mavericks Server

Mavericks has an application called Contacts. Mavericks Server (OS X Server 3) has a service called Contacts. While the names might imply differently, surprisingly the two are designed to work with one another. The Contacts service is based on CardDAV, a protocol for storing contact information on the web, retrievable and digestible by client computers. However, there is a layer of Postgres-based obfuscation between the Contacts service and CalDAV. The Contacts service is also a conduit with which to read information from LDAP and display that information in the Contacts client, which is in a way similar to how the Global Address List (GAL) works in Microsoft Exchange.

I know I’ve said this about other services in OS X Server, but the Contacts service couldn’t be easier to configure. First, you should be running Open Directory and you should also have configured Apple Push Notifications. To setup Push Notifications, have an Apple ID handy and click on the Contacts entry in the SERVICES section of Server app.

Screen Shot 2013-10-05 at 10.30.27 PMClick the Edit button to configure the Apple Push Notification settings for the computer. When prompted, click on Enable Push Notifications.

Screen Shot 2013-10-05 at 10.31.08 PMIf prompted, provide the username and password for the Apple ID and then click on Finish.

To enable the Contacts service, open the Server app and then click on Contacts in the SERVICES section of the List Pane. From here, use the “Include directory contacts in search” checkbox to publish LDAP contacts through the service, or leave this option unchecked and click on the ON button to enable the service.

Screen Shot 2013-10-05 at 11.03.35 PMThe Contacts service then starts and once complete, a green light appears beside the Contacts entry in the List Pane. To configure a client open the Contacts application on a client computer and use the Preferences entry in the Contacts menu to bring up the Preferences screen. From here, click the Accounts menu and then click on Add Accounts.

Screen Shot 2013-10-05 at 10.49.18 PMAt the Add Account screen, click Other contacts account.

Screen Shot 2013-10-05 at 11.05.03 PMAt the “Add a CardDAV Account” screen, select CardDAV from the Account type field and then provide a valid username from the users configured in Server app as well as the password for that user and the name or IP address of the server. Then click on the Create button.

Screen Shot 2013-10-05 at 11.08.23 PMWhen the account is finished creating click on the Server Settings tab if a custom port is required. Otherwise, close the Preferences/Accounts screen and then view the list of Contacts. Click on the name of the server in the Contacts sidebar list. There won’t be any contacts yet, so click on the plus sign to verify you have write access to the server.

Next, let’s get access to the LDAP-based contacts. To do so, bring up the Add Account screen again and this time select LDAP from the Account Type field.

Screen Shot 2013-10-05 at 11.13.03 PM

Provide the name or IP address of the server and then the port that LDAP contacts are available over (the defaults, 389 and 636 with SSL are more than likely the settings that you’ll use. Then click on the Continue button.

Screen Shot 2013-10-05 at 11.13.43 PM

At the Account Settings screen, provide the name that will appear in the Contacts app for the account in the Description field and then enter the search base in the Search base field. To determine the search base, use the serveradmin command. The following command will output the search base:

sudo serveradmin settings dirserv:LDAPSettings:LDAPSearchBase

Then set Authentication to simple and provide the username and password to access the server for the account you are configuring. The list then appears.

The default port for the Contacts service is 8443, as seen earlier in the configuration of the client. To customize the port, use the serveradmin command to set addressbook settings for BindSSLPorts to edit the initial array entry, as follows:

sudo serveradmin settings addressbook:BindSSLPorts:_array_index:0 = 8443

The default location for the files used by the Contacts service is in the /Library/Server/Calendar and Contacts directory. To change that to a folder called /Volumes/Pegasys/CardDAV, use the following command:

sudo serveradmin settings addressbook:ServerRoot = "/Volumes/Pegasys/CardDAV"

The service is then stopped with the serveradmin command:

sudo serveradmin stop addressbook

And started with the serveradmin command:

sudo serveradmin start addressbook

And whether the service is running, along with the paths to the logs can be obtained using the fullstatus command with serveradmin:

sudo serveradmin fullstatus addressbook

The output of which should be as follows:

addressbook:setStateVersion = 1
addressbook:logPaths:LogFile = "/var/log/caldavd/access.log"
addressbook:logPaths:ErrorLog = "/var/log/caldavd/error.log"
addressbook:state = "RUNNING"
addressbook:servicePortsAreRestricted = "NO"
addressbook:servicePortsRestrictionInfo = _empty_array
addressbook:readWriteSettingsVersion = 1

If you’re easily amused, run the serveradmin settings for calendar and compare them to the serveradmin settings for addressbook:

sudo serveradmin settings calendar

By default, the addressbook:MaxAllowedInstances is 3000. Let’s change it for calendar:

sudo serveradmin serveradmin settings calendar:MaxAllowedInstances = 3001

And then let’s see what it is in addressbook:

serveradmin settings addressbook:MaxAllowedInstances

Mac OS X Mac OS X Server Microsoft Exchange Server

Configuring Calendar Server in Mountain Lion Server

Configuring Calendar Server in Mountain Lion Server is a fairly simple and straight forward process. The Calendar Server is a CalDAV Server, leveraging HTTP and HTTPS, running on ports 8008 and 8443 respectively. To enable the Calendar service in Mountain Lion Server, open the Server application and click on Calendar in the SERVICES section of the sidebar.

Enabling the Calendar Server in Mountain Lion Server

Enabling the Calendar Server in Mountain Lion Server

Once open, click on Edit to enable email notifications of invitations in the Calendar Server. Provide the email address and then click on the Next button.

Mountain Lion Server :: Configuring Email Notifications in Calendar Server

Mountain Lion Server :: Configuring Email Notifications in Calendar Server

At the Configure Server Email Address screen, provide the type of incoming mail service in use, provide the address of the mail server and then the port number used, if not a standard port for HTTPS-based IMAP (or POP if you’d prefer), the user name and the valid password for the account. Then click on the Next button.

Mountain Lion Calendar Server :: Configuring IMAP

Mountain Lion Calendar Server :: Configuring IMAP

At the outgoing mail server screen, provide the Outgoing Mail Server address, the port, whether or not SSL is in use (it should be if possible), the password protocol, the user name and the password. Then click on the Next button.

Mountain Lion Calendar Server :: Verify Settings

Mountain Lion Calendar Server :: Verify Settings

At the Mail Account Summary screen, review the settings and if correct, click Finish. Back at the service configuration screen, click on the plus sign (“+”) and provide a type of location, a name for the location, whether or not invitations to the resource are accepted and then enter the account name for any accounts that can manage the location’s calendar (they will auto-complete, so there’s no need to remember users and groups exactly). Click Done to complete the setup. Use the Resource setting in type to configure a resource instead of a location. The two are the same, except the Type field.

Creating Locations in the Calendar Service of Mountain Lion Server

Creating Locations in the Calendar Service of Mountain Lion Server

There are a number of settings that can also be configured. But those are exposed only at the command line. To configure them, open the command line and then review the list of Calendar service settings using the list option of the serveradmin command:

sudo serveradmin settings calendar

One of the more common settings to configure is the port number that CalDAV runs on. To configure HTTP:

sudo serveradmin settings calendar:HTTPPort = 8008

For HTTPS:

sudo serveradmin settings calendar:SSLPort = 8443

You can then start the service using the start option:

sudo serveradmin start calendar

Or to stop it:

sudo serveradmin stop calendar

Or to get the status:

sudo serveradmin fullstatus calendar

Once the Calendar server is configured, use the Calendar application to communicate with the server. Open the Calendar application and click on the Calendar menu and select Preferences. From the Preferences screen, click on Accounts to bring up a list of accounts. Here, click on the plus sign (“+”) to bring up the “Add an Account” screen.

Adding An Account In Mountain Lion's Calendar App

Adding An Account In Mountain Lion’s Calendar App

At the “Add an Account” screen, select CalDAV from the Account Type menu and then enter the User Name and password configured on the server, as well as the address of the server. The User Name is usually the name provided in Server app, followed by @ and then the address of the server.

Account Settings In Mountain Lion's Calendar App

Account Settings In Mountain Lion’s Calendar App

Once the server is configured it appears in the list of accounts in the sidebar of the Calendar app. Create calendars in the account and then to share a calendar, right-click on the calendar and click on Share Calendar…

Sharing a CalDAV Calendar

Sharing a CalDAV Calendar

At the Share Calendar screen, provide the name the calendar should appear as to others and click on the plus sign (“+”) and enter any accounts to delegate administration to.

Mountain Lion Calendar Settings

Mountain Lion Calendar Settings

Back at the Calendar Settings screen, use the settings to configure Availability and refresh rate of calendars, as seen above. Click on Server Settings to assign custom port numbers.

Mountain Lion Calendar Address Screen

Mountain Lion Calendar Address Screen

Click on the Delegation tab to view any accounts you’ve been given access to.

Account Delegation In Mountain Lion's Calendar Server

Account Delegation In Mountain Lion’s Calendar Server

Use the Edit button to configure who has delegated access to calendars, as opposed to configuring subscriptions.

Overall, the Calendar service in Mountain Lion Server is one of the easiest to configure. Most of the work goes into settings configured on client systems. This, as with Exchange, dedistributes administration, often making administration more complicated than with many other tools. But that’s a good thing; no one wants to access other peoples accounts, for calendars or mail for that matter, without those users knowing that it was done, as will happen when resetting passwords…

public speaking

MacTech InDepth In New York

I have been added as a speaker at MacTech InDepth in New York. If you haven’t signed up yet, and you work with Mac OS X Server then you should really check out the sessions that have been planned:

  • The Elephant in the Room: The New Lion OS X is out, now what? There are a lot of differences to contend with between Lion and Snow Leopard. Now with the new Mountain Lion update, what changes can we expect to see? We discuss the differences in advanced services, GUI simplicity, and Apache management GUI’s. We help you understand the updates in the new OS and make the transition easier. We go over the new updates of Lion over the Snow Leopard server.
  • Setting solid foundations: To truly grasp the power of Lion, you need to set up solid foundations. We go over minimum requirements for internet DNS, and tackle router tricks. We discuss open directory and what it was used for.
  • Mobile Device Management 101: Apple’s IPCU/Apple Configurator: Mobile Device Management is vital to businesses, large or small. We have an extensive overview of profile manager and how you can use mobile device management on OS X. For those still using Snow Leopard, we go over your options and discuss the possibility of using third parties as a solution.
  • DNS, Ahh, run away, run away: In this session, we tackle DNS and break it down and show how simple it is to work with. We go over how DNS works and cover different components such as internet DNS and internal DNS.
  • Administering a Server with just Server.app: We show you how to use server.app and control administrative programs. For the services, we go over Address Book, iCal, iChat, and Mail.
  • Web Administration of OS X Server : Web Admin on Lion Server versus Snow Leopard is covered, dealing with the differences and how to use each system effectively. On Lion server, we cover using FTP without a GUI.
  • Going old school, using the old tools: After getting used to Snow Leopard we go over the major differences between Snow and Lion and how you can handle the transition. We go over server admin and what is still left in the program and why it has been left.
  • Deployment Part I: Tools & Concepts: In tools and concepts we learn that there aren’t stark differences between Lion server and Snow Leopard. NetBoot, NetRestore and third party tools are covered; we talk about how NetBoot works and what the differences between NetBoot and NetRestore are. Along with this we cover Network configuration requirements and using software update server.
  • Deployment Part II: DeployStudio: DeployStudio is covered in-depth; we cover creation techniques and management techniques.

Overall, this represents a nice, fast way to update your skills to allow for managing Lion Server and to get up to speed with those new to the platform. One thing I like about the session list is that it goes beyond the stock server implementation and looks at DeployStudio, MDM and other important topics not purely server oriented. I hope to see you all there!

These vagabond shoes, are longing to stray
Right through the very heart of it – New York, New York

Mac OS X Server

Fixing Service Issues When Upgrading to 10.7.3 Server

The 10.7.2 to 10.7.3 update for Lion Server has introduced a few issues in some environments that I’ve seen. It just so happens that the update corrects a lot of behavior with Lion Server while also introducing new features, so it’s something you’re gonna’ need to do eventually. Therefore, before I update, I would strongly recommend backing up all of your services, your service data and Open Directory.

Once you’ve run the 10.7.3 update, there are a few things that I’ve seen happen. The first is that the web server won’t start. If this happens, reset the web server back to factory default:

serveradmin command web:command=restoreFactorySettings

Once it’s reset, you should be able to import any data that was backed up before and get things back to normal. The second is calendar data. On a few different systems I’ve seen users have to nuke iCal and then reimport data. To nuke and pave iCal, see this post: http://krypted.com/mac-os-x-server/nukepave-ical-server-in-lion-server. Once iCal Server has been restored to full working order (after the last step in that article) you can use psql to restore your data from the location of your backups (here called /backup/caldav.sql):

psql -U _postgres -d caldav -f /backup/caldav.sql

There’s also a script located in /usr/share/caldavd/lib/python/calendarserver/tools
called fix calendardata.py that can be used to scan and possibly fix any issues with the data itself. If that doesn’t not work though, you may be starting over. The script does not give root execute permissions by default and so you will need to chmod it to provide execute and then run it.

If you nuke CalDAV and you nuke OD and then restore them both, the GeneratedUIDs can be mismatched. Use the Directory Editor in the new Directory Utility to browse users and attach the GeneratedUID back to the correct entry in CalDAV. To locate all of the entries in CalDAV, run:

psql -U _postgres caldav -c “select * from calendar_home"

If Profile Manager won’t load it could be one of three issues (in the following order seemingly). The first is the web server, which the first command will fix. Another issue I’ve seen is that Open Directory gets a little messed up. The fix for this is to use Server Admin (not slapconfig) to burn OD down and set it back up. You can then promote replicas and finally restore the archive you did before upgrading the server. The third is to reset the Profile Manager database using wipeDB.sh:

sudo /usr/share/devicemgr/backend/wipeDB.sh

After wiping the data, you can re-run the setup in Server app for the Profile Manager service to restore an empty Profile Manager instance to working order. You can restore data into the empty Profile Manager database using the same commands I showed earlier for CalDAV, just use devicemgrd instead.

Note: I am pretty sure you need sudo for most every command I use on this site, but more specifically you need it with this stuff. So sudo is assumed if not explicitly stated.

Finally, be on the lookout for custom designs in the Wiki interface. OS updates are known to change things, but more specifically when things are not documented they can easily change. Hacking the pages nested within /usr/share/collabd is basically not supported any more. Each OS update to 10.7 has broken some of the hacks we’ve done to collabd, making me wonder whether it’s a good idea any more…

Note2: I have had little issues running these updates in walled gardens. It’s production data that is the problem. It seems that most of the issues are data driven (the opposite of data driven design is not devops driven design).

Mac OS X Server

Nuke+Pave iCal Server in Lion Server

It is possible to remove all of the content from a Lion Calendar server using Postgres. To aid you in doing so, Apple has built out a couple of commands to make the process easier. This will nuke everything from the server and so is not something that should be lightly done. To do so, first stop the Calendar service in the Server application. Then let’s back up the database:

pg_dump -U _postgres caldav -c -f /db_backups/caldav.sql

Then run dropdb to remove the database itself:

dropdb -U _postgres caldav

Once the database is gone, run the calendar_bootstrap_database script (I prefer doing so verbosely):

calendarserver_bootstrap_database -v

Now you should be able to start a fresh, clean calendar database by starting up the Calendar service in the Server application again. Note, this is dangerous if you have production data. Also note that you cannot run the bootstrap until you delete the database.

Mac OS X Server Mac Security Time Machine

Using ServerBackup to Backup Lion Servers

ServerBackup is a new command included in Lion Server, located in the /usr/sbin/ServerBackup directory. The ServerBackup command is used to backup the server settings for services running on a Lion Server. The command is pretty easy and straight forward to use, but does require you to be using Time Machine in order to actually run.

In the most basic form, ServerBackup is invoked to run a backup using the backup command. Commands are prefixed with a -cmd followed by the actual command. As you might be able to guess, the commandlet to fire off a backup is backup. The backup command requires a -source option which will almost always be the root of the boot volume (/):

/usr/sbin/ServerBackup -cmd backup -source /

The data backed up begins in a .ServerBackups directory on the root of the host running Time Machine. Once the backup is complete the data is moved over to the actual Time Machine volume, using a path of:

/Volumes/<TimeMachine_volume_name>/Backups.backupd/<hostname>/<date>/<GUID>/<Source_Volume_Name>/.ServerBackups

The output of a backup should look similar to the following:

2012-02-01 10:05:17.888 ServerBackup[15716:107] Error encountered creating ServerMetaDataBackupFolder at path := /.ServerBackups!
*** nextPath := 40-openDirectory.plist
*** nextPath := 45-serverSettings.plist
*** nextPath := 46-postgresql.plist
*** nextPath := 55-sharePoints.plist
*** nextPath := 65-mailServer.plist
*** nextPath := 70-webServer.plist
2012-02-01 10:05:18.480 ServerBackup[15716:107] SRC := /etc/apache2/
DST := /.ServerBackups/webServer
Failed to copy /etc/apache2/ to /.ServerBackups/webServer/etc/apache2; ret -> 0
2012-02-01 10:05:18.483 ServerBackup[15716:107] SRC := /etc/certificates/
DST := /.ServerBackups/webServer
Failed to copy /etc/certificates/ to /.ServerBackups/webServer/etc/certificates; ret -> 0
*** nextPath := 75-iChatServer.plist
*** nextPath := com.apple.ServerBackup.plist
curServicePath := /.ServerBackups/openDirectory/openDirectory.browse.plist
WARNING: Service openDirectory folder does not exist for browsing.
curServicePath := /.ServerBackups/serverSettings/serverSettings.browse.plist
WARNING: Service serverSettings folder does not exist for browsing.
curServicePath := /.ServerBackups/postgresql/postgresql.browse.plist
WARNING: Service postgresql folder does not exist for browsing.
curServicePath := /.ServerBackups/sharePoints/sharePoints.browse.plist
WARNING: Service sharePoints folder does not exist for browsing.
curServicePath := /.ServerBackups/mailServer/mailServer.browse.plist
WARNING: Service mailServer folder does not exist for browsing.
curServicePath := /.ServerBackups/webServer/webServer.browse.plist
WARNING: Service webServer folder does not exist for browsing.
curServicePath := /.ServerBackups/iChatServer/iChatServer.browse.plist
WARNING: Service iChatServer folder does not exist for browsing.

There are usually a lot of warnings, as any given server might not be in use on the server. There is a postBackupComplete commandlet that is supposed to remove the .ServerBackups directory following the backups; however, the default behavior seems to be to remove the directory without requiring that option.

You can then view the backup snapshots by path (they can also be viewed by cd’ing straight into them):

/usr/sbin/ServerBackup -cmd list

To delete a snapshot from the list shown (where <PATH> is a path from the output of list):

/usr/sbin/ServerBackup -cmd purgeSnapShot -path <PATH>

The backup files themselves are actually the service name followed by a .conf extension; however, the data in the configuration files are just the output of a serveradmin settings of the service, such as what you would get from the following:

serveradmin settings afp > afp.conf

For running services, there’s also a .status file (personally, I’d prefer a .fullstatus file instead if I had my druthers). While all services are exported, and can be manually restored by flipping that > from the above command to a <, some services can also be restored using the services commandlet. To see a list of services that are backed up specifically and can be granularly installed as an option:

/usr/sbin/ServerBackup -cmd services

To restore:

/usr/sbin/ServerBackup -cmd restore -path /Volumes/VOLUMENAME/Backups.backupdb/HOSTNAME/SNAPSHOT -target /

To restore a specific service (for example, the iCal Server):

/usr/sbin/ServerBackup -cmd restoreService -path /Volumes/VOLUMENAME/Backups.backupdb/HOSTNAME/SNAPSHOT -target / -service

Currently, ServerBackup is not included in the daily, nightly or monthly periodic scripts and it does not back up actual data, just settings, so if you’re going to rely on it, you might need to automate server settings backups as needed. The ServerBackup command does a few pretty cool things. However, there is a lot more work needed to get it to be holistic. We’ve been working on scripts for similar tasks for a long time. For more information on that see sabackup.sourceforge.net (although we’re likely to relocate it to github soon). For more information on ServerBackup itself, see the help page (no man page as of yet):

/usr/sbin/serverbackup -help

To see what version that ServerBackup is using (not actually very helpful but can be used to programatically verify ServerBackup is using the latest version):

/usr/sbin/ServerBackup -cmd version

Supposedly there is a prefs command, but I have yet to actually get it to do anything:

/usr/sbin/ServerBackup -cmd prefs

Finally, if you are scripting this stuff, don’t forget quotes (as you might have a space in the hostname). Also, a quick sanity check to determine size and make sure there’s available capacity using the size command let, which only outputs the required space for a ServerBackup backup:

/usr/sbin/ServerBackup -cmd size

iPhone Mac OS X Server Mac Security Mass Deployment SQL

Working with Postgres from the Command Line in Lion Server

Mac OS X Server 10.7, Lion Server, comes with a few substantial back-end changes. One of these is the move from SQLite3 to PostgreSQL for many of the back-end databases, including Wiki and Podcast Producer (collab), Webmail (roundcubemail), iCal Server and Address Book Server (caldav) and as the back-end to the newest service in Lion Server, Profile Manager (device_management). As such, it’s now important to be able to use PostgreSQL the way we once used SQLite3, when trying to augment the data that these databases contains, as there currently aren’t a lot of options for editing this data (aside from manually of course).

Postgres has a number of commands that can be used to interact with databases. The most important is probably psql. Many of the other commands simply provide automated options to psql, and over time I’ve started using psql for most everything. For example, PostgreSQL comes with a command /user/bin/createuser. However, as it’s usually more verbose with errors, I like to use psql to do this. In Lion Server, the only user that can access the Postgres databases is _postgres, installed by default with Lion Server. Because a lot of commands require passwords and we might not always want to provide write access to the databases, we’re going to create a new SuperUser, called krypted with a password of daneel.

To do so, we will have to use the _postgres user to invoke psql. Any time you want to invoke psql with a different user than the user you are currently logged in as, use the -U option. To define a database, use the -d option (device_management providing access to Profile Manager data, caldav to iCal Server data roundcubemail to WebMail data and collar to Wiki data). To string this together, for accessing the device_management database as _postgres:

psql -U _postgres -d device_management

To then create a new user called krypted with a password of daneel we’ll use the create option, defining a user as the type of object to create, followed by the user name and then with password followed by the password (single quoted) and then createuser; as follows:

device_management=# create user krypted with password 'daneel' create user;

Now that there’s a valid user, let’s see what else we can do. To see all of the tables, use d:

device_management=# d

As you can tell, there are a bunch of them. Run the help command to see a list of SQL commands that can be run and ? for a list of psql options. To put some SQL commands into action, we’re going to look at the tasks that have been performed by Profile Manager. These are stored in the tasks table (aptly named), so we’re going to run the following SQL query (note a space followed by a semi-colon is required at the end of this thing):

device_management=# select * from "public"."tasks" limit 1000 offset 0 ;

Or to make it a bit simpler if you don’t have a lot of data in there yet:

device_management=# select * from "public"."tasks" ;

After seeing the output, you’ll probably be a little appreciative of Apple’s formatting. Next, let’s look at dumping the databases. We’re going to create a folder on the root of the volume called db_backups first:

sudo mkdir /db_backups

This is where these backups will end up getting stored. We’ll continue using the _postgres user for now. To do our database dumps, we’re going to use pg_dump, located at /usr/bin. First, we’ll dump the device_management database (but first we’ll stop the service and after we’ll start it – all commands from here on out also assume you’re sudo’d):

serveradmin stop devicemgr
pg_dump -U _postgres device_management -c -f /db_backups/device_management.sql
serveradmin start devicemgr

And the other 3 (stopping and starting each in the process):

serveradmin stop web
pg_dump -U _postgres roundcubemail -c -f /db_backups/roundcubemail.sql
serveradmin start web
serveradmin stop wiki
pg_dump -U _postgres collab -c -f /db_backups/collab.sql
serveradmin start wiki
serveradmin stop addressbook
serveradmin stop calendar
pg_dump -U _postgres caldav -c -f /db_backups/caldav.sql
serveradmin start addressbook
serveradmin start calendar

I haven’t had any problems running the dumps with the services running, but it’s better safe than sorry I guess. I’d probably also add some logging and maybe dump the output of full status for each service to try and track if all is well with each. Any time a service didn’t fire back up I’d then build in a sanity check for that event. There’s also a database for postgres itself, so let’s back that up as well since we’re here:

pg_dump -U _postgres postgres -c -f /db_backups/postgres.sql

These can then be restored using psql with the -d option to define the database being restored into and the -f option to define the file being restored from. For example, to restore collab:

psql -U _postgres -d collab -f /db_backups/collab

The databases are all dumped daily using pg_dumpall. These are stored in /var/pgsql but can be changed using serveradmin settings (for example, to move them to /var/pgsql1):

serveradmin settings postgres:dataDir = "/var/pgsql1"

If you mess up the Profile Manager database (before you put any real data into it) you can always use the /usr/share/devicemgr/backend/wipeDB.sh script to trash the database and start anew (although I’d just use a snapshot of a VM for all this and restore from that).

You can also connect to Postgres remotely, or locally through a network socket (common in Apache uses) by adding a listener. To do so, we’ll need to restart the Postgres LaunchDaemon. First, back up the file, just in case:

cp org.postgresql.postgres.plist org.postgresql.postgres.plist.OLD_CSE

Then stop postgres:

serveradmin stop postgres

Then edit the org.postgresql.postgres.plist file to change the following line:

listen_addresses=

To read:

listen_addresses=127.0.0.1

Then fire up postgres again:

serveradmin start postgres

And now let’s scan port 5432 (the default TCP and UDP port used for postgres) for localhost:

/Applications/Utilities/Network Utility.app/Contents/Resources/stroke 127.0.0.1 5432 5432

We could have used another IP address for the listen_addresses as well, but with that _postgres user not requiring a password it didn’t really seem prudent to do so. Once you’ve enabled a socket, you’ll then be able to use one of the many GUI tools to manage postgres. Navicat is available on the Mac App Store for $5 and PGnJ is a nice, easy to use, free one. There are tons of others, but I don’t spend a lot of time in a SQL GUI and so don’t need more than a cheap app will get me. One nice thing about most of these is that they help you to form SQL queries (or they help me). This can get really nice if you are, for example, trying to get some good reporting on Profile Manager (a feature it’s a bit light on right now).

Finally, don’t do any of this stuff on a production box, except maybe if you want more than nightly backups unless you think pretty hard about what you’re doing and know the exact impact of doing something. If you were to edit the databases on a live boxen, then you can safely assume that with how all of the objects in those databases use GUIDs that you’re probably going to break something, if not bring the whole house of cards tumbling down.