Configure Messages Server in OS X Server 5

Getting started with Messages Server couldn’t really be easier. Messages Server in the OS X Server 5 version of the Server app uses the open source jabber project as their back-end code base. The jabber binary is located at /Applications/ directory and the autobuddy binary is at /Applications/ The actual jabberd binary is also stored at /Applications/, where there are a couple of perl scripts used to migrate the service between various versions as well. Setting up the Messages service is simple. Open the Server app and click on Messages in the Server app sidebar.  Screen Shot 2015-09-22 at 10.39.43 PM Click on the Edit… button for the Permissions. Here, define which users and interfaces are allowed to use the service. Screen Shot 2015-09-22 at 10.41.03 PM From Server app, click on the checkbox for “Enable server-to-server federation” if you have multiple iChat, er, I mean, Messages servers and provide the address for servers to federate to. Screen Shot 2015-09-22 at 10.40.10 PM Next, click on the checkbox for “Archive all chat messages” if you’d like transcripts of all Messages sessions that route through the server to be saved on the server. You should use an SSL certificate with the Messages service. If enabling federation so you can have multiple Messages servers, you have to. Before enabling the service, click on the name of the server in the sidebar of Server app and then click on the Settings tab. From here, click on Edit for the SSL Certificate (which should be plural btw) entry to bring up a screen to select SSL Certificates. At the SSL Certificates screen (here it’s plural!), select the certificate the Messages service should use from the available list supplied beside that entry and click on the OK button. If you need to setup federation, click back on the Messages service in the sidebar of Server app and then click on the Edit button. Then, click on the checkbox for Require server-to-server federation (making sure each server has the other’s SSL certificate installed) and then choose whether to allow any server to federate with yours or to restrict which servers are allowed. I have always restricted unless I was specifically setting up a server I wanted to be public (like public as in everyone in the world can federate to it, including the gorram reavers that want to wear your skin). Screen Shot 2015-09-22 at 10.44.11 PM To restrict the service, then provide a list of each server address capable of communicating with your server. Once all the servers are entered, click the OK button. Obviously, if you only have one server, you can skip that. Once the settings are as you wish them to be, click on the ON/OFF switch to light up the service. To see the status of the service, once started, use the fullstatus option with serveradmin followed by the jabber indicator: sudo serveradmin fullstatus jabber The output includes whether the service is running, the location of jabber log files, the name of the server as well as the time the service was started, as can be seen here: jabber:state = "RUNNING"
jabber:roomsState = "RUNNING"
jabber:logPaths:PROXY_LOG = "/private/var/jabberd/log/proxy65.log"
jabber:logPaths:MUC_STD_LOG = "/var/log/system.log"
jabber:logPaths:JABBER_LOG = "/var/log/system.log"
jabber:proxyState = "RUNNING"
jabber:currentConnections = "0"
jabber:currentConnectionsPort1 = "0"
jabber:currentConnectionsPort2 = "0"
jabber:pluginVersion = "10.8.211"
jabber:servicePortsAreRestricted = "NO"
jabber:servicePortsRestrictionInfo = _empty_array
jabber:hostsCommaDelimitedString = "osxserver.krypted.lan"
jabber:hosts:_array_index:0 = "osxserver.krypted.lan"
jabber:setStateVersion = 1
jabber:startedTime = ""
jabber:readWriteSettingsVersion = 1 There are also a few settings not available in the Server app. One of these that can be important is the port used to communicate between the Messages client and the Messages service on the server. For example, to customize this to 8080, use serveradmin followed by settings and then jabber:jabberdClientPortSSL = 8080, as follows: sudo serveradmin settings jabber:jabberdClientPortSSL = 8080 To change the location of the saved Messages transcripts (here, we’ll set it to /Volumes/Pegasus/Book: sudo serveradmin settings jabber:savedChatsLocation = “/Volumes/Pegasus/Book” To see a full listing of the options, just run settings with the jabber service: sudo serveradmin settings jabber The output lists each setting configurable:
jabber:dataLocation = “/Library/Server/Messages” jabber:s2sRestrictDomains = no jabber:jabberdDatabasePath = “/Library/Server/Messages/Data/sqlite/jabberd2.db” jabber:sslCAFile = “/etc/certificates/” jabber:jabberdClientPortTLS = 5222 jabber:sslKeyFile = “/etc/certificates/” jabber:initialized = yes jabber:enableXMPP = yes jabber:savedChatsArchiveInterval = 7 jabber:authLevel = “STANDARD” jabber:hostsCommaDelimitedString = “” jabber:jabberdClientPortSSL = 5223 jabber:requireSecureS2S = yes jabber:savedChatsLocation = “/Library/Server/Messages/Data/message_archives” jabber:enableSavedChats = yes jabber:enableAutoBuddy = no jabber:s2sAllowedDomains = _empty_array jabber:logLevel = “ALL” jabber:hosts:_array_index:0 = “” jabber:eventLogArchiveInterval = 7 jabber:jabberdS2SPort = 5269
To stop the service: sudo serveradmin stop jabber And to start it back up: sudo serveradmin start jabber It’s also worth noting something that’s completely missing in this whole thing: Apple Push Notifications… Why is that important? Well, you use the Messages application to communicate not only with Mac OS X and other jabber clients, but you can also use Messages to send text messages. Given that there’s nothing in the server that has anything to do with texts, push or anything of the sort, it’s worth noting that these messages don’t route through the server and therefore still require an iCloud account. Not a huge deal, but worth mentioning that Messages server doesn’t have the same updates built into the Messages app. Because messages don’t traverse the server, there’s no transcripts.

My Own List of Common Apple Ports

I’ve been underwhelmed (if that’s a word) by the list of common ports used on the Apple platform recently, so I started my own. It’s available at if you’re interested. It’s also under the Tools menu of the site. And yes, I’m aware that I can cat /etc/services; this includes some rudimentary notes.

Promote A Yosemite Open Directory Replica To A Master

You’ve got Open Directory running and humming beautifully in OS X Server (Server 3.5 on OS X 10.10 Yosemite). You show up to work and the hard drive has died on that perfectly configured Open Directory Master. Luckily, you have a replica and you have an archive of your Master. You can restore or you can promote your Replica to a Master. What to do? Well, I can’t tell you what you should do, but I can tell you that Apple has planned for this. Here, we’re going to look at promoting that Replica to a Master. Because after all, hard drives fail. Let’s look at what all this looks like. Create An Open Directory Archive In order to properly restore an Open Directory Master or promote a Replica to a Master, you’ll need the SSL keys. You should also just keep archives of your Open Directory environment around (albeit in a secure location) because you really never know. To create an Open Directory Archive, which has the keys in it as well as data needed to restore a Master, first open the Server app. From within the Server app, click on the Open Directory service. odrprom1 Towards the bottom of the screen, click on the cog wheel icon. odrprom2 At the menu, click Archive Open Directory Master… odrprom3 When prompted, provide the username and password to the Open Directory environment shown in the Server field and then click on the Connect button. At the Archive Open Directory Master screen, choose a location to create your archive. Also, provide a password for the archive. Click the Archive button when you’re ready to proceed. At the Confirm Settings screen, click Archive. The archive is then created. Keep this safe as it has all your base are belong to us in it. You have to do this proactively. Once the hard drive in that Open Directory Master craps out, you’ll need the Archive to put the pieces of Humpty Dumpty back together again. Promote A Replica To A Master Provided you have a Replica and an Archive, promoting a Replica to a Master couldn’t be easier in OS X Server. To do so, open the Server app from the Replica and then use the cog wheel icon to bring up the menu. odrprom4 Here, click Promote Replica to Master. odrprom5 At the “Promote Open Directory replica to master” screen, provide an Open Directory username and password (e.g. diradmin with the appropriate password). Also, choose the archive you created previously. Then click Next. The Replica will become an archive. Once finished, remove any other replicas and repromote them. Stop Open Directory Another option is to stop Open Directory on the replicas until you can get your Master back up and running. To stop Open Directory, open the Server app and click on the Open Directory service. odrprom6 Click on the OFF button. You’ll then be prompted to verify that you really want to stop directory services on the server. Click OK (which should probably read a bit more ominous, like “OMG, OK”. odrprom7 The server is then stopped. To completely remove Open Directory from the server, run the slapconfig command, followed by -destroyldapserver: slapconfig -destroyldapserver Also, don’t forget to go to the Master and remove any servers from there as well, once they’ve been fully demoted. View the logs using cat for any other weirdness: cat /Library/Logs/slapconfig.log

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…

Upgrading Open Directory From Snow Leopard Server to Lion Server

I don’t believe in upgrading major operating systems for servers in place. There, I said it. If I’m doing an upgrade from Snow Leopard to Lion, I’m about 99.9% of the time going to do so with a clean install. Before I do so, I’m going to export all the data from my old server and when I’m done with the fresh, clean, loving installation, I’m going to import that data back into my server. Actually, before I import the data, I’m going to install all of the point releases, application updates and security patches. That’s my process for production servers. Open Directory isn’t very different. I Archive and Restore servers as often as I reinstall, upgrade or even downgrade Open Directory Masters. I treat Replicas differently: mostly in that I don’t treat them at all. Instead I clean install them and just re-promote them once my Master is back in place. If I have any schema extensions or other mods I’ll just sync those myself prior to promotion. I trust my process, it’s worked for me for more years than I care to admit. Before You Upgrade Archiving Open Directory data is a pretty straight forward process. Open Server Admin from /Applications/Server and then click on the Open Directory service. From here, Click on the Choose… button for Archive in: and select a location to store the Open Directory data. Then, click Archive and provide a password. Pretty easy so far. Now, check your Kerberos Realm, IP address and hostname on the server. For the IP address, you can take screen shots of the Network System Preference pane, or pipe the output of ifconfig to a text file. For the hostname, I don’t trust the GUI of OS X (no offense to the excellent UX developers employed at Apple). Therefore, use scutil for the names. Also, we’ll want that Kerberos information. I usually just grab that from my Server Admin Open Directory screen. Finally, we’re also going to get the OD policies using slapconfig again. In sequence, these commands would be: ifconfig > ~/Desktop/mytextfile scutil --get HostName >> ~/Desktop/mytextfile scutil --get ComputerName >> ~/Desktop/mytextfile scutil --get LocalHostName >> ~/Desktop/mytextfile sudo slapconfig -getmasterconfig >> ~/Desktop/mytextfile sudo slapconfig -getmacosxodpolicy >> ~/Desktop/mytextfile Also, backup any certificates, custom service principals you may have installed or other service data or data data that is needed on the host, if any. Installation Once you’ve got all of the important stuff backed up and know what you’re going to call the server moving forward, it’s time to install the operating system. If the server came with a Lion operating system pre-installed, skip this part. Use a Lion computer to create a recovery partition using the Recovery Disk Assistant. Once you have a valid recovery partition (on a thumb drive for now), boot to it on the server you are upgrading and wipe the system through Disk Utility. This step is probably pretty scary. And it should be. Make sure all your data is backed up before you do it. By the way, if you haven’t copied the mytextfile then think long and hard about whether there’s anything else missing before you start the reformat process on that drive (I seem to have to learn all of my lessons the hard way)… I also like to have a clone of the system as a back-out plan, just in case there are any problems with the upgrade. It adds a little latency but I’ve had to revert a few times with these upgrades, and having that clone sure beats pulling an all nighter… Once wiped, Choose the Reinstall Lion option and install the operating system. Then install all available patches (10.7.3 or higher is very, very important, btw). Once installed, use the App Store to buy Lion Server and install it, but don’t open it just yet. Remember those commands from earlier. When possible, Open Directory upgrades the smoothest when the IP address and host name are the same. Therefore, look at your mytextfile. Setup the IP information the same as it was, verifying against ifconfig and then use the first host name from the scutil output to configure the HostName (using as my example): sudo scutil --set HostName Then the second host name: sudo scutil --set ComputerName And finally, the third: sudo scutil --set LocalHostName mdm Now check changeip: sudo changeip -checkhostname If it gives you the all clear, you’re ready to proceed. Next, download the Server Admin tools from Apple at Provided that the installation is good, the host names match up in scutil and the IP address is the same as it was, open the Server app for the first time (from /Applications). The server will install the various components that complete the installation. Once installed, click on the Next Steps drawer and verify that the host name is good. If it is, you should see a message similar to the one below. Promotion Now promote your server. It’s going to be tempting to use Server Admin or slapconfig. If you use slapconfig you will regret it unless you use the new options supplied by Apple. Why? Because the Server app gracefully creates SSL certificates used in directory services binding; certificates that are not created with the old style slapconfig commands. Given that I’ve not seen complete documentation for slapconfig (many of the options required for correct scripted promotion in Lion aren’t actually in the man page), I’d just use the GUI for now (and if you don’t like using a GUI, then I challenge you to build OpenLDAP, Kerberos and all the other components setup by the Server app from source – that might cure the CLI snobbiness we all have from time to time). Also, be careful with how you promote/demote – this article outlines some reasons not to use slapconfig -destroyldapserver any more. From the Server app, click on Users in the Server sidebar. Here, you’ll notice that all of the accounts that are listed are black busts of users. Groups are similar. So far, all users created are automatically local users. If that’s not what you want, remove any of those accounts prior to continuing. Click on Manage Network Accounts… to bring up the Configure Network Users and Groups wizard. Click Next at the introductory screen. Then provide the Directory Administrator information (e.g. diradmin with a password of diradmin for the security conscious) and click on Next. At the Organization Information enter the information you want on the SSL certificate that is automatically generated for Open Directory. This includes the Organization Name and Admin Email address (this might not be enough information for some SSL providers, but it’s a good start) and click on Next. At the Confirm Settings screen, verify your information is as intended and then click on Set Up. The Open Directory Master is created. Once created, all new users will have the same icon as the local users, with the exception of a globe to indicate they are network accounts. Now check your logs to make sure everything installed smoothly. Importing Users, Groups and Computers Provided that the host name and IP address are the same on your server, importing the data back into Open Directory couldn’t be easier. Open Server Admin and then click on Open Directory and then on Archive in the top icon bar. Here, click on Choose and browse to the dmg you created when backing up the server. Click Restore and enter the password previously supplied. You can also import users from within the Server app. Now that your users are back, it’s time to make sure they’re a member of the groups that provide access to services. These are hidden by default, so in the Server app, use the Show System Accounts option under the View menu or if you’d rather use Workgroup Manager use Show System Records under the View menu to see the groups. Each service has a different group name. For example, Profile Manager is the Profile Manager ACL (or for the short name) group. Add each user into the group that needs access to these services, click Save and you’re ready to bind some clients! Binding Clients Binding clients can be done in a few different ways. You can use a script, a Profile, the Users & Groups System Preference pane or build binding into the imaging process. For the purpose of this example, we’ll use the System Preference pane. To get started, open up the System Preference pane and then click on Users & Groups. From here, click on Login Options and then unlock the lock in the lower left corner of the screen, providing a username and password when prompted. Click on the Edit… button and then the plus sign (“+”). Then, enter the name of the Open Directory Master (the field will expand with options when you enter the host name. It’s probably best not to use the IP address at this point as the master will have an SSL certificate tied to the name. Click OK to accept the certificate (if it’s self-signed) and then the system should finish binding. Once bound, I like to use either id or dscl to verify that directory accounts are properly resolving before I try logging in as an Open Directory user. Provided everything works that’s it. The devil is of course in the details. Good luck!

Replacing the Default SSL Cert For SonicWALLs

The default, self-signed certificate that comes on a SonicWALL causes alerts during a Nessus scan. This is because the device uses a certificate that comes on the device and isn’t signed by a valid CA. Chances are, there are limits around who can load the SonicWALL web interface in the first place. But, if you don’t want Nessus to continue alerting, or if you just want to use a certificate signed by a valid CA because it’s a good security practice, you might want to add a new certificate. The first step is to generate a new CSR. To do so, open the SonicWALL web interface and then click on System in the SonicWALL sidebar. Then click on Certificates and scroll to the bottom of the screen until you see the New Signing Request button. At the resultant Certificate Signing Request screen, fill out the fields with your information. Click on the Generate button to bring up the Export Certificate screen. Click Export and then choose where to save the CSR. Once you receive the certificate, you’ll want to install it. The easiest way to do so is to go back to the Certificates screen (under System in the SonicWALL sidebar) and then scroll down to the bottom, clicking on Import… Here, use Choose File to pick the cert, provide a name for it and the password for it and click on Import. Next, click on Administration (also under System in the SonicWALL sidebar). Scroll down to the Web Management Settings section of the screen and use the Certificate Selection field to select the newly installed certificate. And that’s it. I’ve had to restart the device to get it to work properly, but overall, a pretty straight forward process.

How Exchange's Autodiscover Works With

Autodiscover automatically configures profile settings for Exchange clients. These clients include Microsoft Outlook 2007 or Outlook 2010, Outlook for Mac, in Mac OS X, iPhone, iPad and ActiveSync enabled phones. Autodiscover is often made out to be complicated. There’s an Autodiscover service that gets installed when a Client Access Server (CAS) role is setup for Exchange 2010 in the form of a default virtual directory named Autodiscover for the default Web site in Internet Information Services (IIS). You then forward an autodiscover service locater record in DNS in the form of _autodiscover._tcp. The virtual directory handles Autodiscover requests. But what about other vendors, and even for Exchange, how do you verify that it’s working correctly? If clients automatically configure then it’s working, obviously. But when it isn’t, what do you need to do? The most obvious step is to check that the DNS record responds appropriately. To do so, we can use nslookup. To use nslookup, run it from the command line, followed by the DNS name. For, this might be: nslookup But note that there’s not a response. This is because doesn’t use _autodiscover (why would it, it’s not EWS/ActiveSync after all. But other domains that are configured for autodiscover would respond. For example, look at the output for nslookup Which looks like this: Non-authoritative answer: Name: Address: Provided that the answer section is the address of the CAS Exchange server that sits in front of your organization (the one that runs the Autodiscover virtual directory in IIS) then you are more than likely off to a great start using autodiscover. If not, then that’s the first thing that likely needs to get fixed if you actually want clients to use autodiscvoer. Also keep in mind that you’ll want to check internally and externally, as you will likely have different domain names setup for these. I often find that people will configure the _autodiscover records in their public DNS but not in their private views. Also keep this in mind when acquiring SSL certificates for Exchange’s CAS instance. Note: Autodiscover, as its implemented in Office Exchange clients, also has the ability to change configurations in Office on the fly as network settings change on internal networks (e.g. users get moved to different information stores, IPs of servers change, etc). This does not seem to work with Apple’s Mail. One could write a script to check for a change in the records nightly (or more frequently of course) if this is needed. Sometimes the mail clients can interpret things differently than we do manually from the command line, including autodiscover. When the Apple Mail client is attempting to connect to Exchange, you can also get more information about the EWS autodiscovery process by capturing logs about it, not done by default, but invoked by firing up mail using the –LogEWSAutodiscoveryActivity option followed by a YES, as follows: /Applications/ 
--LogEWSAutodiscoveryActivity YES By reading these logs, you can learn way more than you ever wanted to know (or thought was possible) about Autodiscover. Given that Autodiscover is similar in iOS, most of this rings true in the Mail app there as well. However, given that you can’t view the activity in as granular a detail by invoking Mail through the command line, you can watch it in the logs in iPhone Configuration Utility while you’re setting up Mail, Contacts & Calendars in the Settings app, which should provide information about any connection failures. While Autodiscover is awesome, you should still be able to connect without it. The only time I really both to troubleshoot Autodiscover itself is when I can install an account but I cannot get Autodiscover to eliminate the need for the second setup screen in Mail on iOS and OS X (possibly with the exception of Lion). If you can setup mail, but it requires two screens then the problem is basically always Autodiscover. If you can’t setup mail at all then the problem is basically never Autodiscover. Good luck, and hope someone finds this useful!

Mac OS X Server 10.5: Troubleshooting CalDAV

I originally posted this at So you installed your new server and you’re having a few problems. Let’s look at the common issues and a few simple fixes for them. iCal will not start, with log entries that it is unable to create a virtual host: Check your host name. iCal is going to need the host name to be correct in order to start. Use scutil --get HostName and then make sure that the host name listed in the iCal Server settings is identical to this value. You setup a user, check the box in Workgroup Manager for Enable Calendaring and then save your settings but you get the following error in your logs: Oct 12 15:51:26 cedge Workgroup Manager[2282]: +[WPUser userWithGUID::] returned nil! This is likely caused by the fact that you are enabling a calendar for a local user. Try using an OD based user and see if you get the same error. You got everything started and the account was created for the user but when you add an account in iCal it fails to connect. Make sure that the port that iCal server is using is located at the tail end of the host name for the iCal Server. One issue that we see here is that unless you are using managed accounts then iCal Server is not likely going to append the port number for you iCal Server. Also verify that you can connect to the remote server, and remember that you can always open the URL of the server followed by a : and then the port number and get a login prompt. If you can authenticate to this as the user whose calendar that you are trying to setup then you can use the information in this screen to determine ACL information and other security settings that could be keeping calendars from working. Also keep in mind that while your default port might be 8008 your default port if you are using SSL is actually 8443. Once you get this far, you should be able to create an event and see data listed in the Overview tab for iCal. If so then you should be able to about anything you want in the iCal server. If you prefer to use the serveradmin CLI to control your services, you can also use the serveradmin settings calendar:ServerHostName = "SomeHostName" variable to change your host name. You can also use the calendar:HTTPPort to change the port number you are using for connectivity. Happy Calendaring!!!