You work for weeks, months, or years to build a business that is killing it. Then you get a huge new customer. You feel like you’ve been put on the map. But then the reality sets in. Maybe you won the business because you’re innovative, less expensive, faster, etc. But now you start getting completely destroyed by the overhead of making those sweet, sweet dollars from that new customer. Wouldn’t it have been great to have known about a few things to ask about? My response includes a few tips on how to work with them, that just might save you some serious margin!. Check it out at http://www.inc.com/charles-edge/how-to-work-with-big-companies-without-getting-caught-in-red-tape.html.
krypted November 18th, 2016
Posted In: Articles and Books
OK, I don’t talk politics, about personal stuff, etc on this site usually. And I’m not gonna’ start now. But with Give To The Max Day in Minnesota today, I did write an article on the meaning of Compassion on Huffington Post. It can be found at http://www.huffingtonpost.com/charles-edge/what-does-compassion-mean_b_12999974.html if you’re interested in such things; if not, hope you have a wonderful day!
krypted November 17th, 2016
Posted In: Tamarisk
One of the first things we do when we setup a new macOS Caching Server is to check the logs to see if it’s actually serving content. You can view thee logs at /Library/Server/Caching/Logs/Debug.log. In the log, when a Caching Server has registered for your network, you’ll see a line that begins with the following:
Got request for host = http://swcdn.apple.com/
This above means that the server actually got a request (as it says) and that the request is for an asset at swcdn.apple.com (followed by the actual package path). Once found, the server caches the asset, which starts with the following:
Initializing asset handler for http://swcdn.apple.com/
The path would then match the same asset along with a path=(followed by the path to the asset on your server).
You’ll then see some information and ultimately a list of the number of bytes served from the cache, as well as the number of downloads. If that sits at 0 the server isn’t really doing anything…
krypted November 16th, 2016
Posted In: Mac OS X Server
I thought there might be an easier way to do this. So there’s this binary called serverrails that I assumed would install rails – no wait, actually it’s a ruby script that tells me to ‘gem install rails’ – which fails:
cat `which serverrails`
# Stub rails command to load rails from Gems or print an error if not installed.
version = ">= 0"
if ARGV.first =~ /^_(.*)_$/ and Gem::Version.correct? $1 then
version = $1
gem 'railties', version or raise
puts 'Rails is not currently installed on this system. To get the latest version, simply type:'
puts ' $ sudo gem install rails'
puts 'You can then rerun your "rails" command.'
load Gem.bin_path('railties', 'rails', version)
Given that doesn’t work, we can just do this the old fashioned way… First let’s update rails to 2.2 or 2.2.4 using rvm, so grab the latest rvm and install it into /usr/local/rvm:
sudo curl -sSL https://get.rvm.io | bash -s stable --ruby
Then fire it up:
sudo source /etc/profile.d/rvm.sh
Then install the latest ruby:
sudo rvm install 2.2
Set it as default:
sudo rvm use 2.2 –default
Then run your gem install:
gem install rails
krypted November 14th, 2016
Stoked that we got to interview Michael Lynn (@mikeymikey) for the MacAdmins podcast. It turned out to be a great episode on the future of Mac management and MDM. I’m glad we were able to have him join in! Pepijn and Marcus did a great job as well, so all round, a great episode. Hope you enjoy!
Or find it on the Podcast site at http://podcast.macadmins.org/2016/10/24/episode-13-mdm-me-maybe/
krypted October 24th, 2016
Automating OS installations is going to eventually be about as easy on macOS as it is in iOS (er, if you have MDM that is). But in the meantime, it’s getting a bit more challenging. The obvious way Apple would prefer this to happen these days is via the startosinstall command that first shipped with El Capitan and with brtool getting moved around all the time, and becoming less of a thing, there’s one quick and easy thing you can do:
sudo "/Applications/Install macOS Sierra.app/Contents/Resources/startosinstall" --applicationpath "/Applications/Install macOS Sierra.app" --agreetolicense --nointeraction --volume /Volumes/Macintosh\ HD
In the above command, we’ve dropped “Install macOS Sierra.app” on a machine. While you’d guess that it would find the application path based on its own surname, we went ahead and supplied it as that seems to basically be a thing. Basically, –agreetolicense keeps us from having to run some expect scripts to accept a license agreement, –nointeraction suppresses as many of the screens as possible, and –volume allows us to install to any volume we’d like. This isn’t fully automated, but I have been able to layer in some more logic to quit apps before the script fires and then expect out other items from the script to automate a restart, watching for osinstallersetupd as a key.
This is all a bit bulkier than just using something like createOSXinstallPkg but it’s important to mention that there are a number of system components that are allowed for in SIP that use osinstallersetupd and so this blessed mechanism is likely the future until you can trigger an OS upgrade (and update I suppose) using an MDM command.
krypted October 23rd, 2016
The macOS Server5.2 Guide is basically complete. There are a number of services in the server, each explored here: http://krypted.com/guides/os-x-server-5-2-sierra/. Good luck out there!
krypted October 20th, 2016
Posted In: Mac OS X Server
A wiki is a repository of dynamically created and managed content, or content created or edited by multiple users collaboratively. This article is about using the wiki service in macOS Server 5.2 (the Apple Server app running on 10.12/Sierra). I reference file services with WebDAV because it is a very nice integration piece that I think a lot of people will find pretty beneficial.
To get started with the Wiki service, first turn it on. This one isn’t heavily dependent on host names (other than being able to access the server from a browser) or directory services (other than being able to authenticate users, but local accounts are perfectly functional) and it doesn’t require the Websites service to be running as well. One should always have good working directory services and host names, still…
To enable the service, open the Server app and click on Wiki in the list of SERVICES in the List Pane.
There are two configuration options. The first is to select who is able to create wikis. Use the “Wikis can be created by” drop-down list to select “all users” if anyone with an account on the server should be able to create a wiki or “only some users” to bring up the Wiki Creators screen.
If only some users can create new wikis, use the plus sign (“+”) at the Wiki Creators screen to add users and/or groups to the list of users that can create wikis. Click on OK when all users and groups that can create wikis are added. In a school I would imagine that only teachers or IT staff would be able to create wikis. Once a wiki is created, pages inside the wiki can still be created by non-wiki creators.
The other option available is the handy dandy WebDAV interface to the wikis. When you enable this option, you can connect to a server from OS X or iOS via WebDAV and access files in each wikis document repository. To be clear, this option doesn’t provide access to the user documents, but does provide access to the wiki documents. We’re going to check the box for “Enable WebDAV access to Wiki files” and then click the ON button.
Once the service starts, click on the View Wiki link in the Wiki workspace in Server app.
Here, click on the Log in button and enter a user with access to the server, preferably one who can create wikis.
At the Wikis page, you will then see a list of all wikis you have access to. Note that the previous screen showed one wiki and now we see two. That’s because one of the wikis has permissions that allow “All unauthenticated users” access to the wiki, which we’ll describe shortly. The first thing most administrators will do is create a wiki. To do so, click on the plus sign (“+”) icon on the web page and at the resultant screen, click on New Wiki.
At the “Create a new wiki” prompt, provide a name for the wiki and a brief description for it.
Click on Continue.
At the Set permissions screen, enter each user or group to provide access to edit and view wiki pages. Here, you’ll have the options for Read & Write (users can view and edit pages in the wiki), Read only (users can only view the contents of your pages) and No access (users have no access to the wiki). There is a group for All logged in users, which includes every user with access to the server and another for All unauthorized users, which includes guests to the server. Once you’ve given the appropriate permissions, click on Continue.
Note: You don’t have to get this perfect now as you can always edit these later.
At the Set Appearance screen, you can choose an icon for the wiki (shown in the wiki list and when you open the wiki) as well as a color scheme for the wiki. Choose the appropriate appearance for your wiki (again, you can always change this later) and then click on the Create button.
Once the setup is finished, you’ll see the Setup complete modal. Here, you can click on Go to Wiki button.
Once you’ve created your first wiki, let’s edit it and customize the content. To do so, click on it from the list of available wikis. Click on the cog-wheel icon and then Wiki Settings… to bring up the Wiki Settings page.
Here, you’ll see the previously entered name and description as well as options to enable Calendar (only available if Calendar Server is running on the server) and Blog, which enables a blog service for the wiki (wiki administrators can post blog entries to the wiki). Click on Appearance.
Here, you will have the previous two options as well as the ability to upload a banner (which should be 62 pixels high) and background for each wiki.
Click on Permissions. Here, you’ll see the permissions previously configured as well as options to configure who can comment on articles (nobody disables comments completely) in the wiki and whether comments require approval (moderation).
Click on Save. Now, let’s edit the splash page. To do so, click the pencil icon in the top navigation bar.
At the edit screen, the top nav bar is replaced by a WYSIWIG editor for managing the page. Here you can justify, link, insert media and of course edit the text you see on the screen. I recommend spending some time embedding links, inserting tables, making text look like you want it to and editing the content to reflect the purpose of the wiki. Click Save when you’re done. Click the pencil again to edit it, and let’s create a new wiki page. Keep in mind that link wikipedia, each page should be linked to from other pages in the order they should be read. Unlike most wikis, there’s actually an index page of all the articles, which can come in handy.
From the edit page, to create a new page and link to it, enter some text (or lasso some) that you’ll use as the link to access the new page you’re creating. Then click on the arrow and select “New page.”
Note: Use Enter URL to link to an existing page or an external website, instead of creating a new page.
At the New Page screen, provide a name for the new page (the lasso’d text automatically appears as the Page Title) and click on the Add button.
Click Save and then click on the newly created link. You can now edit the new page the same way you edited the previous pages. Click on the disclosure triangles in the right sidebar to Comment on articles, link articles to related articles, tag articles and view editing history.
Now for the fun part. Click on Documents. Here, you’ll see the pages you already created. Click on the plus sign and select the option to Upload File to the wiki.
At the Upload File dialog, click on Choose File and then select a file to upload.
Click Upload when selected.
Then from the Finder of a macOS client, use the Go menu to select “Connect to Server”. Enter the name or IP of the server and then click on Connect.
Assuming you can access the server, you should then be prompted for a username and password. Enter it and click Connect. Eventually, the file(s) will display (it can take awhile according to your network speeds and how many files are in the directory). You can connect to this same screen through an iPad using a 3rd party WebDAV client or the build in options in Pages.
Managing wikis is as easy as its ever been, with the new options for appearance being a nice add-on. Active Directory integration is as easy as binding the server to Active Directory and using the accounts listed in Permissions of pages.
Now that iOS devices can edit wikis and many of the traditional word processing options are available in the wiki editor, consider what the Wiki can be. Could it replace text editing apps for iOS? Could the Wiki allow for more collaborative documents than a Word or other document editor? Could it keep from getting eaten like the rest of the homework? Could the comments in the Wiki be a good way for teachers to have students write responses to materials? Could the Wiki and the document management features allow your workers to access human resources documents and employee manuals? I know plenty of tech firms that use wikis to track information about the systems they manage.
Once you have all of this information, upgrading can seem downright scary. But fear not, there’s Carbon Copy Cloner. And once you’ve cloned, there’s wikiadmin. 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 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
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…
krypted October 17th, 2016
Posted In: Mac OS X Server
The Time Machine service in macOS Server 5.2 hasn’t changed much from the service in previous operating systems. To enable the Time Machine service, open the Server app, click on Time Machine in the SERVICES sidebar. If the service hasn’t been enabled to date, the ON/OFF switch will be in the OFF position and no “Backup destination” will be shown in the Settings pane.
Click on the ON button to see the New Destination screen, used to configure a list of volumes as a destinations for Time Machine backups. The selection volume should be large enough to have space for all of the users that can potentially use the Time Machine service hosted on the server. When you click the Choose button, a list of volumes appears in a standard Finder selection screen.
Here, click on the volume to save your backups to in the sidebar. In most cases the Backup destination will be a mass storage device and not the boot volume of the computer. Once selected, click Choose and then if desired, limit the amount of storage on the volume to be used for backups. Click Create and a share called Backups is created and the service will start. Don’t touch anything until the service starts. Once started, add a backup destination at any time using the plus sign button (“+”) and defining another destination.
Time Machine Server works via Bonjour. Open the Time Machine System Preference pane and then click on the Select Backup Disk button from a client to see the server in the list of available targets, much as you would do with an Apple Time Capsule.
Under the hood, a backup share is creating in the file sharing service. To see the attributes of this share, use the serveradmin command followed by the settings option and then the sharing:sharePointList:_array_id:, so for a path of /Volumes/New Volume 1/Shared Items/Backups use:
sudo serveradmin settings sharing:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups
The output indicates the options configured for the share, including how locking is handled, guest access disabled, generated identifiers and the protocols the backups share listens as:
sharing:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:name = "Backups" sharing:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:smbName = "Backups" sharing:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:nfsExportRecord = _empty_array sharing:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:afpIsGuestAccessEnabled = no sharing:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:isTimeMachineBackup = yes sharing:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:dsAttrTypeNative\:sharepoint_group_id = "F4610C2C-70CD-47CF-A75B-3BAFB26D9EF3" sharing:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:isIndexingEnabled = yes sharing:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:mountedOnPath = "/Volumes/New Volume 1" sharing:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:dsAttrTypeStandard\:GeneratedUID = "FAB13586-2A2A-4DB2-97C7-FDD2D747A0CD" sharing:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:path = "/Volumes/New Volume 1/Shared Items/Backups" sharing:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:smbIsShared = no sharing:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:smbIsGuestAccessEnabled = no sharing:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:afpName = "Backups" sharing:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:smbDirectoryMask = "755" sharing:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:afpIsShared = yes sharing:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:smbCreateMask = "644" sharing:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:ftpName = "Backups" sharing:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:timeMachineBackupUUID = "844A1C43-61C9-4F99-91DE-C105EA95BD45"
Once the service is running, administrators frequently fill up the target volume. To move data to another location, first stop the service and then move the folder (e.g. using mv). Once moved, use the serveradmin command to send settings to the new backup path. For example, to change the target to /Volumes/bighonkindisk, use the following command:
sudo serveradmin settings sharing:sharePointList:_array_id:/Shared Items/Backups:path = "/Volumes/bighonkindisk"
Another way to see the share and attributes of the share is through the sharing command:
Which should show output similar to the following:
List of Share Points
path: /Shared Items/Backups
guest access: 0
inherit perms: 0
guest access: 0
guest access: 0
There’s also a Bonjour service published that announces to other clients on the same subnet that the server can be used as a backup destination (the same technology used in a Time Capsule). One major update from back in Mavericks Server is the addition of the timemachine service in the severadmin command line interface. To see the command line settings for Time Machine:
sudo serveradmin settings timemachine
The output shows that share info is displayed as with the sharing service, but you can also see the GUID assigned to each share that is a part of the backup pool of storage:
timemachine:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:dsAttrTypeStandard\:GeneratedUID = "FAB13586-2A2A-4DB2-97C7-FDD2D747A0CD" timemachine:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:smbName = "Backups" timemachine:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:afpIsGuestAccessEnabled = no timemachine:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:smbDirectoryMask = "755" timemachine:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:afpName = "Backups" timemachine:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:smbCreateMask = "644" timemachine:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:nfsExportRecord = _empty_array timemachine:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:path = "/Volumes/New Volume 1/Shared Items/Backups" timemachine:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:smbIsGuestAccessEnabled = no timemachine:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:name = "Backups" timemachine:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:ftpName = "Backups" timemachine:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:smbIsShared = no timemachine:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:afpIsShared = yes timemachine:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:timeMachineBackupUUID = "844A1C43-61C9-4F99-91DE-C105EA95BD45" timemachine:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:isTimeMachineBackup = yes timemachine:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:backupQuota = 0 timemachine:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:dsAttrTypeNative\:sharepoint_group_id = "F4610C2C-70CD-47CF-A75B-3BAFB26D9EF3" timemachine:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:isIndexingEnabled = yes timemachine:sharePointList:_array_id:/Volumes/New Volume 1/Shared Items/Backups:mountedOnPath = "/Volumes/New Volume 1"
Additionally you can also query for the service to verify it’s running using full status:
sudo serveradmin fullstatus timemachine
Which outputs something similar to the following:
timemachine:command = "getState" timemachine:state = "RUNNING"
While I found plenty to ramble on about in this article, Mass deployment is still the same, as is client side configuration.
krypted October 15th, 2016
Configuring Calendar Server in macOS Server 5 (running on Sierra) 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 macOS Server 5.2, first open the Server application and click on Calendar in the SERVICES section of the sidebar.
Once open, click on Enable invitations by email to enable email notifications of invitations in the Calendar Server. Provide the email address and then click on the Next button.
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.
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.
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.
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 /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin settings calendar
There are a number of settings for the Calendar service, including the following:
calendar:DefaultLogLevel = “info”
calendar:EnableAPNS = yes
calendar:EnableSSL = yes
calendar:DirectoryAddressBook:params:queryUserRecords = yes
calendar:DirectoryAddressBook:params:queryPeopleRecords = yes
calendar:EnableSearchAddressBook = yes
calendar:HTTPPort = 80
calendar:AccountingCategories:HTTP = no
calendar:AccountingCategories:Implicit Errors = no
calendar:AccountingCategories:iTIP = no
calendar:AccountingCategories:migration = no
calendar:AccountingCategories:AutoScheduling = no
calendar:AccountingCategories:iSchedule = no
calendar:AccountingCategories:iTIP-VFREEBUSY = no
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:EnableCardDAV = no
calendar:Scheduling:iMIP:Sending:UseSSL = yes
calendar:Scheduling:iMIP:Sending:Server = “osxserver.krypted.com”
calendar:Scheduling:iMIP:Sending:Address = “email@example.com”
calendar:Scheduling:iMIP:Sending:Username = “com.apple.calendarserver”
calendar:Scheduling:iMIP:Sending:Password = “79PreYsZSFfZZC6v”
calendar:Scheduling:iMIP:Sending:Port = 587
calendar:Scheduling:iMIP:Enabled = yes
calendar:Scheduling:iMIP:Receiving:UseSSL = yes
calendar:Scheduling:iMIP:Receiving:Server = “osxserver.krypted.com”
calendar:Scheduling:iMIP:Receiving:Type = “imap”
calendar:Scheduling:iMIP:Receiving:Username = “com.apple.calendarserver”
calendar:Scheduling:iMIP:Receiving:Password = “79PreYsZSFfZZC6v”
calendar:Scheduling:iMIP:Receiving:Port = 993
calendar:SSLPrivateKey = “”
calendar:LogLevels = _empty_dictionary
calendar:DataRoot = “/Library/Server/Calendar and Contacts/Data”
calendar:ServerRoot = “/Library/Server/Calendar and Contacts”
calendar:SSLCertificate = “”
calendar:EnableCalDAV = no
calendar:Notifications:Services:APNS:Enabled = yes
calendar:SSLPort = 443
calendar:RedirectHTTPToHTTPS = yes
calendar:SSLAuthorityChain = “”
calendar:ServerHostName = “odr.krypted.com”
One of the more common settings to configure is the port number that CalDAV runs on. To configure HTTP:
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin settings calendar:HTTPPort = 8008
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin settings calendar:SSLPort = 8443
You can then start the service using the start option:
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin start calendar
Or to stop it:
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin stop calendar
Or to get the status:
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/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 Add Account. From the Add Account screen, click on Add CalDAV Account radio button and click Continue.
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.
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…
At the Share Calendar screen, provide the name the calendar should appear as to others and anyone with whom you’d like to share your calendar with. 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.
Click on the Delegation tab to view any accounts you’ve been given access to.
Use the Edit button to configure who has delegated access to calendars, as opposed to configuring subscriptions.
Overall, the Calendar service in Server 5.2 is one of the easiest to configure on Sierra. 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…
krypted October 14th, 2016
Posted In: Mac OS X Server