Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Reid Bundonis

Pages: 1 2 [3] 4 5 ... 8
While everyone is highlighting the final paragraph of the ruling, I believe this one is even more powerful and inspiring.

The nature of injustice is that we may not always see it in our own times. The generations that wrote and ratified the Bill of Rights and the Fourteenth Amendment did not presume to know the extent of freedom in all of its dimensions, and so they entrusted to future generations a charter protecting the right of all persons to enjoy liberty as we learn its meaning. When new insight reveals discord between the Constitution’s central protections and a received legal stricture, a claim to liberty must be addressed.

America grows and learns.  Each generation must experience its own epiphany and act on it to improve our nation and culture.  There was a time when slavery was acceptable.  There was a time when women could not vote.  There was a time when water fountains, lunch counters, baseball, and buses were segregated.  The prevailing generations accepted these injustices as social norms.  Yet it was the responsibility of the next generation to see the flaws in those long held practices.  This is how we advance as a nation.  This is how we evolve to not remain blindly stuck in the past, doomed to repeat the mistakes, prejudices, and shortsightedness of our forefathers.  It may take time, but America learns from its mistakes.

It has been a long time since I've felt pride in our government's ability to accomplish anything.  But the decision by the Supreme Court is a great advance for all in our nation, further advancing civil rights and continuing to strive to one day completely satisfy the foundation principle:

We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness.

Yosemite Server - Foundation Services / Book Version 1.2 Posted
« on: May 05, 2015, 03:38:35 PM »
Server 4.1 is out and it is a good one.  Port 311 is working again.  Protecting with third party SSL certificates is working again.  Flat file export is now built in.  These are all good signs of an improving product.

Look for the update shortly as it was just submitted to Apple for review.

No problem.  Keep those servers running!

Ok, let's get back to the promotion of network accounts to mobile accounts.

...but how would you handle situations where the users are already local network users, but need to be "promoted" to mobile users? (Edit To add: For example these users having been using a MacBook on the network for a year but now we are going to allow the MacBooks to be taken out of the office. They were also already set up with a local home folder on the machine.) Maybe I am missing something, or maybe it is just because I fear that I've gone too far and backtracking may be in order to do things correctly.

Ok, so Apple has a number of home folder types.  There is the local account.  An example is the admin account created when you setup a new Mac.  The account is local on the machine and requires no infrastructure to function.

Next, you have network accounts.  This is what you have accomplished.  This is done by creating an OD domain and then binding the workstation to the domain.  As long as the domain user account has a valid home folder path, the user will be able to login to a bound Mac using domain credentials.  A local home folder will be created but the user's account attributes will not be cached to the machine for offline use.  Should the network, the server, or anything in between the client and the server fail, the user will have no access to her data.

Next, there are network home accounts.  In this case, you still are using domain accounts but instead of the home folder being created on the workstation, a special network mount is used to allow the user's home folder to mount from the server.  This is really only good in schools or other short duration environments in which user mobility is critical.

And finally, there is what you are looking for... The mobile account.  This is a domain account that creates a local home folder AND caches the users credentials for offline use.

So how to create this?  Relatively simple.  You have two methods of doing this.  The legacy MCX method still works in 10.10 but Apple clearly would prefer using a configuration profile.  Here is the quick cheat sheet:

MCX:  If you are doing MCX, then you will:
1:  Bind the machine to the domain (you have done this already)
2:  Using Workgroup Manager, select a group (or you can do this by the user but that is less efficient) and press the Preferences tab.
3:  Press Mobility and define you setting.  Basically, they are to set Always, check "Create mobile account when user logs in to network account" and then set home as local home template.
4:  Save this and reboot the workstation.
5:  Log in as user. 
6:  Later, you can uncheck the "Require confirmation before creating mobile account" once you are happy with the results.

Profile Manager:  If you are running Profile Manager or another MDM, you can use the Mobility payload to effectively set the same preference.
1:  Bind machine to domain and enroll into MDM.  Keep in mind that enrolling into MDM can perform the bind so the steps can be simplified.
2:  Once again, set the payload on a group or group of computers
3:  Select the Mobility payload and check "Create mobile account when user logs in to network account" and then set home as local home template.
4:  Experiment with other settings

Once the profile is pushed to the workstation, login as the domain users.

Either of these methods should "convert" the network account to a mobile account.  Disconnect the machine from your network and reboot.  Confirm that you have access to the account.

The other problem I am wondering about is where you talk about not mixing MCX and Profile Manager. Can you expand a little on that? I have workgroup manager installed but I don't think it was ever really used for anything. If I remember correctly I attempted to use it when I ran into some issues with creating local home folders for users, but I am not sure it was what fixed the problem. This might sound like a strange question but is there a way to tell if MCX has a hand in the way things are running?

So MCX is depreciated and there is no promise than any of the settings will work going forward.  That being said, "most" everything still works in Yosemite.  But the writing is clearly on the wall.  Apple wants MCX buried and Configuration Profiles put on a pedestal.

One of the easiest ways is to launch Workgroup Manager and select the Preferences tab.  Select all users and all groups.  If you have no arrow next to a payload, then you have not set MXC values.  You can also use mcxquery but that will likely be tedious.

Ok, hope that clears it up.

Ok, Catching up to the first post.  Sorry.  Busy day.

SSL Certificates

Single Site Certificates are designed to protect single servers with a single host name.  For example, if your server's fully qualified host name is you will purchase a certificate matching that URL.  Now, once you have another server or device (SonicWall) you will really want to get another cert and address that device by a unique name.  The reason for this is that while the OS X Server is not accessed externally now, it may at some point in the future.  If you use the cert for both devices, you might run into some trouble.  However, to be honest, you likely could get away with it if you used one IP address and then port port forwarding.  From the outside world, the address would terminate at your public address so the sonic wall can respond to ports and services that it is controlling.  Then when you hit a service that needs to be port forwarded, you will route to the OS X Server and it will reply on the same host name.  In theory, it might work.

- I need to install an SSL on our firewall that has a public static IP address.

Again, you might be able to reuse the cert on both devices.  But as you said, there cost is so low it may make sense to get a unique cert for the SonicWall.  Plus, if you do this, then the public URL could be instead of using the name of a LAN resource (your server).

It seems like I am going to run into problems but I am not sure why. I guess I am trying to understand why there is even a need for an SSL on the server in the first place when it does not have an external IP. Plus, how does it validate without a public IP address? Or does it even matter

Many server deployments never need an SSL cert.  I generally install it on most deployments because customers always say they want to server to do a, b and c.  Then 12 months down the line they say, now I need it to do p, q, r, s, and z.  And three of those are public facing services.  I generally like having the cert in place for the inevitable.  And no, the server does not need a public address.  SSL certs do not contain IP address information, only host name.  The host name must match the certificate and servers that are accessible through NAT or PAT work fine with SSL certs.

Long story short, if I install a SSL cert on the firewall (named that has a public IP will this cause me any issues?


I tell anyone that asks about switching to an OS X Server to go buy your book.

Thanks!  I really need to finish the 4th book.  Will try and post more tonight.

Great!  I am so glad to get the good feedback.  Let's see if I can help you out.

Converting local to mobile
I have always found that KBase article ( to complicated.  I prefer a simpler method.  And you are correct.  I detailed this in “Migrating Accounts From Local To Domain” on page 99 of the “Mavericks Server – Control and Collaboration”  But this is for local accounts that you want to move to domain accounts. 

Sounds like you have network accounts but you do not yet have mobility enabled to allow the caching of the account.  There are two solutions for this.  Either you use MCX and the Mobility payload (this is for legacy systems 10.8 and before) or you use Profile Manager and use the Mobility payload to define the mobile account.  The basics here are that the device is bound to the domain (for account visibility) and that you deliver a config profile or MCX for the mobility payload. 

I will address the second part later today.

Yosemite Server - Foundation Services / Book Version 1.1 Released
« on: March 16, 2015, 12:48:00 PM »
Wow!  Time is flying.  Finally got a 1.1 release out.  New layout, new content.  Go Yosemite!

Yosemite Server - Foundation Services / Re: RADIUS Chapter
« on: January 09, 2015, 01:41:20 PM »
Awesome!  I am glad this is working out. 

Regarding the logging, some of the logs on OS X have restrictive permissions.   You might try:

sudo -s

That will promote the admin to "root".  Then tail the log like:

tail -f /var/log/radius/radius.log

I am on the road but I believe the radius.log is one of those logs that is set to 600 (rw by owner, and --- for everyone else.

Yosemite Server - Foundation Services / Re: RADIUS Chapter
« on: January 05, 2015, 11:26:08 AM »
On the surface, it sounds like this should work.  My guess is this can go one of two ways.  Either you add each AP or you add the controller.  I am going to bet on the controller option since it sounds like Meraki is aggregating the requests through the controller.

Now the one piece I am not sure about is the Meraki interface for were you set the RADIUS values.  I would start here:

If the Meraki is sending the RADIUS auth to the controller, then to the RADIUS server, then I am going to guess that you need to do the following:

1:  Determine the IP of the Meraki controller.  Let's assume it is
2:  Determine the IP of the OS X Server.  Let's assume it is
3:  On the OS X Server, run the -addclient to add the controller as the client.

sudo radiusconfig -addclient NameOfController

You will be prompted for a shared secret.  That must be used in the Meraki Dashboard

4:  Install the certs as per the books instructions, associating an SSL cert with the Radius service.
5:  complete the remaining steps to get OD auth working

6:  In the Meraki Dashboard, add the server as a RADIUS server and enter the shared secret.

7:  Start RADIUS
8:  Use the dashboard to test the authentication.

Let me know if this works.

Yosemite Server - Foundation Services / Re: RADIUS Chapter
« on: January 04, 2015, 11:52:06 AM »
Happy New Year!

Sorry for the delay in replying.  I took a few days off to recharge the batteries and allow the old year to fade and the new to start.

May I ask which APs you are using?

And no, Airports are not a requirement.  I used Airports in the book as this is a common field find for us.  Small businesses who go the Apple route tend to go all in with Apple products.  However, if you are using SonicPoints, Aerohive, or others, you should be able to integrate the radius authentication.  As shown in the book, I commonly configure SonicWall firewalls into the RADIUS allowing for VPN authentication to OD instead of replicating the accounts.

Share with me the products that you are using.  If I come up with the solution and you are up for it, I will add it to the book so that it may help others.

Mavericks Server - Foundation Services / Re: File Share Error
« on: November 07, 2014, 01:45:07 PM »
I am glad the books helped out!  That is great to hear.

So Promise gear is one of our favorites.  Both the FC arrays and the Pegasus.  The price to performance of those Pegasus arrays make it an easy sell and easy to support.  We tend to always ship with a shelf spare drive and so far, so good on those units.  Both the 1 and the 2.  Can't speak highly enough about them.  And with the promiseutil command line tool, you can do anything.

I am not familiar with the G-Speed but I am sure it is fine.

The writing is on the wall for AFP.  Apple has put four years of development into their own SMB client.  Sooner or later, it is going to work properly.  10.7 was a mess.  10.8 got better.  10.9 got worse.  10.10 seems to be better.  Too soon to tell.

In enterprise, 2014 has been the year of the retired Xserves :(  And since there is no hardware that satisfies data center requirements, the options are Windows servers.  I've done just about every migration I can think of this year.  Xserve to Windows Cluster Server.  Xserve to Windows file share.  Xserve to NAS appliances.  Xserve to Windows with ExtremeZ-IP.  In all the Windows cases, the performance of SMB has been as slow as 1/4 that of AFP from the Xserves.  10.9 is faster than 10.8.  But, many users have been very frustrated by these moves.  My hands are tied as the direction of the business is the centralize the file services data on a single platform that they know how to support.  I understand this.  But it remains frustrating.  The best solutions I've seen are the moves to ExtremeZ-IP.  It is the only solution that provides reliable search.

Ok, I am off topic.  Long week and I simply don't feel like doing much today :)  Sorry for the rant on the Drobo.  Over the years we have collected our darlings and our goats.

Hope this helps and keep those OS X Servers running!

Mavericks Server - Foundation Services / Re: File Share Error
« on: November 06, 2014, 08:25:12 PM »
Welcome.  Please realize that this is all my opinion and every environment is different.  Oh, and I should mention that this landscape is changing constantly.

So...  SMB under Mavericks is a double edged blade.  If you are ONLY supporting OS X systems, then it "should" be acceptable.  Performance is nearly on par with AFP.  However...  Once you try to support Windows workstations....  Ugh.  Train wreck.  Disaster.  Plague.

(I should point out here that my testing of SMB on Yosemite is showing performance BETTER than AFP when going Mac to Mac Server.  This is the first time ever that SMB performance has exceeded AFP on a Mac Server.  I am still in the middle of my Windows client testing so I am not ready to reveal results yet.)

Based on this (not talking Yosemite), AFP remains my default protocol in all supported environments running 10.9.x or prior.  I've not moved to SMB because AFP is something that remains constant and customizable.  Plus, I have a number of customers who love their Classic OS legacy.  (Can you say ƒ at the end of a folder name... I know it is a folder.  I've always known it is a folder.  Look the icon is a folder!  I don't need a latin lower f to tell me it is a folder!)  Oh, am I yelling?  And then there is the spaces and special characters...  Oh, boy.  Folders like "     Really important" and "•••••••I am first" to make them bubble to the top.  SMB handles this poorly. 

Now, I will admit, I am lucky enough not to be supporting iWork in any locations.  All my customers are Office users to the core (enterprise compatibility).  So I have not run into the issues you are experiencing.  However, the AutoSave alert is normal for any applications that support Apple's NSDocument autosave.  This includes TextEdit, iBooks Author, Numbers, and others.  So far, I have not seen data corruption with these applications.  The issue is that a network volume does not contain the .DocumentRevisions-V100 folder (look on the root of your hard drive to see what I am talking about).  By the way, this is not to say that Office is perfect.  The locked file bug is making me crazy in mixed environments but I've mitigated it by disabling sleep on all systems.

However, I've never seen AFP drop a RAID.  I see from the thread that you are using a Drobo.  Now this is my opinion, but I've always seen the Drobo as a bad product.  We refuse to sell it to customers and if we run across someone who has one we do everything in our power to get them off it.  (I had one customer with data so critical I ate half the cost of a RAID to get them on something I trusted.)  I still recall Drobo coming to our office way back when they introduced their first product.  The rep said, "a drive can fail and everything keeps working..."  As he said that, one of my techs reached out and ejected a drive (ya, we are those kind of people).  The unit bricked itself and kernel panicked the host.  The red faced tech profusely apologized as he scrambled to save face.  From that point forward, we were skeptical.  Every time we have run across one there has been issues.  Corrupt volumes, unexplained disconnects, drives that just go south and never recover.  I can go on an on.  So my fear is that you are dealing with a component failure, not a protocol failure.  Again, I don't know your environment so this is speculation based on a lot of prior experience.

One way to determine is create an AFP share on the internal drive or a drive other than the Drobo.  See if it fails.  Repeat all your tests.  Remember, you will get the AutoSave alert when saving to any volume.  But create a private share on the boot volume and try there.  See if you can replicate the 0k issue.

If not, then I fear the Drobo is doing to you what I have seen it do to everyone else... DraiNo.  Down goes your data.

So, a future looking statement.  SMB3 in Yosemite "might" be an improvement.  As mentioned, this is the first time Apple removed the checksumming on SMB.  And it is beating AFP so far in isolated testing.

I am glad you are finding the books helpful.  I am working on getting the revision of Control and Collaboration out and am working on the third in the series.  It should be a good one :)

New operating system, new book!  I've gone through Foundation Services and updated it for Yosemite.  Includes almost 20 more pages of content.  I rearranged some areas for better flow, and pointed out the differences introduced in Yosemite.

I will admit, I am excited about a new operating system for the first time in a long time.  If you are looking to upgrade, make sure you follow the upgrading best practices.  It is still early to give Yosemite the "production ready" blessing, but so far the lab experience has been positive.

I should point out that this is Foundation Services.  While there is change, there is not significant change.  DNS is still DNS.  DHCP remains important.  Open Directory is a cornerstone.  Not to discourage sales, but readers who have Mavericks Server – Foundation Services, already have the knowledge needed to properly deploy these services under Yosemite.  Sure, some stuff has changed.  Yes, I want to sell books.  But I am also realistic.  Apple has not changed these topics dramatically.

Thank you for both of these!  Corrected in the Yosemite update.

I can't tell you how many times I've read these pages.  And yet there are still these little errors.  I blame it on bit shift :)

Busy day.  Lots to absorb.  Currently rolling through three Yosemite Servers to see what I can break.

Please keep the suggestions coming.  Working on getting Yosemite updates for Foundation Services and Control and Collaborate out.  Plus building a nice Advanced Topics book.

Added 5 more pages.  This section details how to interact directly with the Profile Manager database and perform queries to get data.

I've upgraded 9 production servers (various customers) since the release of 10.9.5 and Server 3.2.1.  So far, no issues.  Follow my advice from Foundation Servers.  Know your server and be prepared for trouble.  Luckily, I've had none.

I've slowed down because of the Shellshock exploit.  I never realized how many 10.5.x servers we are still supporting...  Dang, I needed to even compile for PPC.  This has given us new work.

I am neck deep in Yosemite at this point.  With the GM seed posted it is time to start screen grabs.

Pages: 1 2 [3] 4 5 ... 8