AntonioRocco

Hidden directories are invisible for a reason and I would not advise making them permanently visible. You don't want just anyone fiddling with the underpinnings of the OS do you? To access hidden directories in OS X click on the Go Menu and select Go to Folder. At the prompt key in /var. If you want to start from the hidden parent folder it would be /private. It's advisable to use Terminal when accessing hidden folders as it preserves the special permissions required by most of the files/folders you see. Using Terminal you'd issue: cd /var/db Followed by a simple list command: ls -la To delete something using Terminal either navigate to that directory using cd or provide the full path. For .ServerSetupDone it would be: rm -Rv /var/db/.ServerSetupDone To find out which directory you're in use the pwd (print working directory) command: pwd Antonio Rocco (ACSA)

Hi There's no need to wipe the server and reinstall the OS as OS X Server is simply an app and not an operating system. To start over, place the Server App in the trash and delete the following items: /Library/Server /Library/Preferences/com.apple.serverd.plist /Library/Preferences/com.apple.servermgrd.plist /Library/Preferences/PrivilegedHelperTools/com.apple.serverd /var/db/.ServerSetupDone /var is a hidden folder. Reboot and on successful login move the Server App back to the Applications folder. Launch it and start again. As seawolf has said avoid .local as the tld for your domain. You should not be using it anyway as it now how its own RFC: .local - Wikipedia, the free encyclopedia If you can't avoid it because your Windows domain is built using it you will have random and intermittent problems. Antonio Rocco (ACSA)

Hi If any of the ports listed in this article are blocked Profile Manager won't work properly: OS X Server: Ports used by Profile Manager 2196 is the port used by clients trying to access APNS to 'receive' the 'pushed' (via port 2195) profile. Blocking or hampering access to both ports as well as 5223 may result in what you're seeing. It's possible APNS itself is having a problem? Has happened in the past. Although not definitive you can test access to APNS by clicking on the 'manage your certificates' section in the Server App for Push Notification Service. Log into the linked portal with the AppleID you used to set it up in the first place. To test PM availability run a port scan on your MDM server internally as well as telnetting to the ports PM requires internally and externally. However the fact that some of them are not receiving the profile but most do may indicate a network routing issue especially if your environment consists of multiple subnets. However I have seen this problem before some time ago and after testing everything suggested here the only 'cure' in the end was to blitz the macs involved. A bit drastic I know but if you've a well defined and crafted Mac deployment solution it should not take long? Antonio Rocco (ACN)

@ mac_shinobi There are variations to some of your questions that go beyond the scope of this forum. IMO these would be better addressed one-to-one in a real-world situation. Hopefully some of what follows might help though? Fristly a brief note first regarding managed policies on a Mac that might be news to others? As of 10.7 Apple began to deprecate MCX in favour of Profile Manager. In its current version (Mavericks 10.9) you really should be using Profile Manager and not WorkGroup Manager although YMMV. You can still install the application on Mavericks and it still does work after a fashion for 10.9 clients. It should really be used for supporting legacy clients (10.7, 10.8) only. Q1) - I apply some (not all) managed policies (either MCX via WGM or XML plists via PM or even both) sitting at a client workstation that’s preconfigured as much as possible the way the customer wants it mostly. This is done by gatthering all the plists and associated files and folders needed and loading them either into WorkGroup Manager and/or Profile Manager as well as placing key files/folders/scripts that can’t be handled by WGM or PM into the BSD sub-system. Other managed policies are applied during the deployment phase using either NetBoot, DeployStudio, Munki or a combination of all three or post deployment using ARD, DeployStudio or Munki or again a combination of all three. Generally managed policies are logically applied to the groups that are more receptive to those policies, eg: dock settings to OD User Groups and power settings to OD Computer Groups and so on. I rarely do much or apply anything from or on the Mac Server itself. About the only thing I do is set up a RAiD (if it’s wanted); any redundancy (if it’s wanted); configure PM and OD; followed by NetBoot and/or DeployStudio and/or Munki. Once the above is done I then sit down and have a discussion about back-ups. Q2) - There’s a number of ways to do this. Simplest being using a Mac (laptop would be ideal) that has WGM installed that’s on the same subnet as the rest of the Macs. Sometimes this will involve moving from room to room as the subnets will invariably be different depending on which room you’re in. Because WGM is basically Bonjour aware and does not traverse subnets easily it makes sense to do it this way. Involves a bit of leg-work sometimes but that does not bother me as I fancy a walk every now and then. Another way is to poll the MAC addresses in the AD OU the Macs have been placed in. If you prepare the ground properly prior to deployment it’s relatively easy to set up a database that has the desired computer name mapped to its MAC address. Import the .csv file into WGM and that should be it. You can do the same thing with Passenger or DeployStudio. Q3) - Order does not really matter unless you’re concentrating on applying all your managed policies at computer level. In which case I would add OD first as it tends to work better. Otherwise AD followed by OD always works for me. At one site I did see some strange behaviour in a virtualized environment where adding OD first was the only cure to inconsistent logins. Turned out it was poorly set-up in the first place which the managed solution contractor were reluctant to change because of the work and budget involved. Q4) - I can’t think of anything definitive for any of this anywhere TBH. There are lots of useful resources out there. One of them being edugeek! Can’t do worse than Charles Edge on Krypted.com. AFP548 of course. Even Apple have something useful once in a while. You’ll have to dig for those though. Back when 10.4 was first released and AD Integration became a real possibility I did produce a manual of sorts (mostly command line) which I published and released to a select few. Setting up a Mac Server is fairly simple and involves three golden rules: DNS, DNS and DNS. Get that bit right and everything else will follow. In an AD environment that’s not necessarily under your control so you will have to get familiar with how Microsoft does things in terms of its DNS and DHCP offerings. It’s also important to be at least familiar with what a Windows Server is and how Active Directory works for anyone wishing to integrate Macs. As time has gone on I’ve found the more I know about the Windows network the easier and therefore more successful it becomes to integrate Macs. Finally getting the magic triangle (I prefer AD-OD integration) set up properly is mostly about how well the AD environment has been set up in the first place. Antonio Rocco (ACN)

Hi You usually see that error message when you're trying to write or make changes to the AD User/Group database from an application that can't make those kind of changes. Open Directory and LDAP are not the same as Active Directory so the best you can ever hope for is read only access using WorkGroup Manager. One way (there are others) to make this work is to create an OD group first using WorkGroup Manager and add/nest AD Users or Groups within it. Apply MCX from there. Once you bind mac workstations to both directories (AD and then OD) policies will be applied. I'm not having a go or anything but it makes no sense to blame the platform for your failings? Antonio Rocco (ACSA)

Unlike PCs Macs are very choosy about the environment you place them in. They're a little like Goldilocks because everything has to be 'just right'. With that in mind I would start with the usual suspects. In no particular order these tend to be: 1. DNS 2. Where possible avoiding the use of a .local domain 3. If home folders are hosted on another server (i.e. not on the DC) or a network resource such as a NAS, make sure you specify the FQDN of that share when defining the home folder location in the Profiles tab. It's a good idea to do this anyway. Don't forget to add an A and PTR Record for that resource in case you haven't done so already. 4. DNS 5. Check permissions allow at least traverse/read rights from the parent folder downwards to user homes 6. Disable IPv6 on client workstations 7. Did I mention DNS? How to check DNS? On any mac client login as the local admin and launch the Terminal App. You'll find it in /Applications/Utilities. Once launched use nslookup and verify you can resolve your DC on the forward and reverse pointers. Something like: nslookup yourdc.yourdomain.yourtld 172.16.16.254 nslookup 172.16.16.254 yourdc.yourdomain.yourtld By default the AD plug-in is set to re-authenticate mac workstations every 14 days. If your AD environment has no such requirement it's a good idea to disable the setting, which you can't using the GUI. Back to Terminal again and issue this command: sudo dsconfigad -show At the prompt key in the local admin's password. There's no echo in Terminal so you won't see this being typed. Inspect the settings. If you see an entry that lists 14 days issue this command: sudo dsconfigad -passinterval 0 Issue the first command again and verify the setting has taken. Hopefully the above should begin to help you track the problem down or at least help us help you a little more? Antonio Rocco (Apple Consultants Network)

Hi I may be stating the obvious but it's possible you may have purchased a single license version instead of the multi-license version you really wanted? Have you verified what you've really bought with the supplier and/or software developer? HTH? Antonio Rocco (ACSA)

Hi Applying policies to an OD Computer Group means the computer itself is managed for all users be they local or over the network. The fact the problem follows only this one user regardless of which mac he logs onto makes me doubt you're doing this at computer group level? Are you sure you're making the change to the right group? Using WorkGroup Manager to manage dock policy via computer groups is not the way I would recommend managing Active Directory users and/or groups and lack of training can be easily remedied. HTH? Antonio Rocco (ACSA)

Hi Is the affected user part of the AD Group nested in the OD group you're applying the policy too? If not add the user to the AD Group. If it's still not working try adding the user account to the OD group instead or as well. Do you see this behaviour regardless of which mac (assuming you have more than the two you've mentioned) the user logs onto and if it's a wired or wireless connection? Antonio Rocco (ACSA)

Hi You don't need to supply credit card information when creating an AppleID or when 'purchasing' a free app. Creating an iTunes Store, App Store, iBooks Store, and Mac App Store account without a credit card Antonio Rocco (ACSA)

Hi @seawolf - Thank you for your input. @irsprint84 - Thanks once again for the info. A minor point but POSIX permissions should be: Owner : root : R/W Group : staff : R/O Everyone : R/O For ACLs there should be an entry for an account that has authority for the AD Domain and a group or groups you want to have mac home profiles for. If it's everyone in your AD database I would add the domain users OU. What the screen grab does not show is the share structure itself. In other words which folder are you sharing. A screen grab of appropriate SACLs for the group would be helful. FWIW I doubt very much if a University is going to move away from Active Directory simply because of the initial investment. If it's still not working after that then my best advice is to: (1) Look to get someone on site who you can discuss your requirements with and (crucially) knows what they're doing and/or (2) Re-think what it is you want to do. Basically seawolf's advice is as sound as anything else offered here. HTH? Antonio Rocco (ACSA)

Hi The screen grab above seems to indicate nested folders? Up to a point this is OK but you must make macuser directory/folder the share for home folder creation and not the Students directory/folder. What you have may be the 'Windows' way but it is not the 'Mac' way. There's no real equivalent to OUs in Apple's LDAP offering hence the reason why I've suggested moving away from Active Directory. On the mac server where and how are you applying permissions exactly? Antonio Rocco (Apple Consultants Network)

Hi I'm beginning to understand and thanks for explaining further. Yes it would be difficult to create and support compared to having shares on your SAN. To be precise yes from 10.7 onwards you will have difficulty setting up home drives on a Mac server for users that don't exist on that server and that exist on another server/directory. Of course you can set up similar on your Windows Server easily because that's where your users are. But that's not what you want to do. In an effort to simplify things and if there's no compelling reason to keep it why don't you remove the AD environment altogether? Keep the Windows Servers by all means as they are better at providing network services such as DNS and DHCP than OS X Server and simply set up an OD environment instead? Open Directory is Apple's Active Directory. Single Sign On will still be there as the OD Master will be the KDC for the network. Export the users you already have in AD using whatever tools you're comfortable with and import them into Open Directory. Delete them from AD when you're done. On the mac server define a folder for home folders and share it. Try to keep the folder/share structure as simple as possible. Avoid nesting folders within folders. Select your users and select the newly created share for home folder creation. Server.app will do the rest including assigning appropriate permissions. Finally make sure those users are given appropriate SACLs (Service Access Control Lists) to use the file sharing service (SMB or AFP). On the client side join the macs to your OD Server (no need for AD and use the LDAP connector instead) and login with a network account. That should be it. If you don't want to do the above leave things as they are and give the AD admin account as well as desired AD Groups read/write ACLs for the share you create on the mac server. In AD specify the home folder location using UNC (drive letter etc). If at the point when you click create/apply you get an error it would be difficult to help further via this forum. If you don't get an error you should be good to go although you may get problems later on when network users start logging in. You might find they can't write to their own home folders on successive logins after the initial one. This can be fixed but not easily unless you're familiar with UNIX and how POSIX permissions work. However 3rd-Party tools such as Passenger offer a GUI drive method of repairing and applying POSIX permissions if that situation arises. Some points you should be aware of: OS X server admin tools such as the Server.App and Profile Manager struggles with more than 500/1000 users. The deprecated WorkGroup Manager application also struggles with more than a 1000 users and in this iteration of the Server (10.9) will work but may create other unexpected problems. For management you should be using Profile Manager and applying policies at hardware level rather than user/group level as before. Hopefully the above should help and may move you on further than where you are now? Antonio Rocco (Apple Consultants Network)

Hi "So your saying with a clean Windows 2012 domain, Mac OSX server OD I can't has AD home drives from that Mac Server?" No, not exactly. Pretty much anything can be made to work within reason and if the budget allows. As ever it depends on what you want to do exactly; how hard you want to work to achieve it and how easy it is to support. What's interesting - assuming I've understood correctly - is the business want things the same as it was in a very old version of the OS, which did not work anyway. This I'm struggling to understand? Firstly technology moves on without much regard with what went before and if it 'failed' before, why would it work now? Perhaps someone needs to manage expectations in a realistic way? It's difficult to advise any further on a forum such as this (good as it is) without being made aware of exactly what you want to achieve. Sorry I could not help you more. Antonio Rocco (Apple Consultants Network)

Hi Maybe I'm mistaking what you're asking but may I ask why you want to use the Mac Server hardware for storing home directories and which home directories do you mean exactly? I'm asking because if your plan is have separate profiles for students logging onto macs than the profiles they access when logging onto PCs then it's not going to work. Prior to OS X 10.7 this was known as Augmented Records. With 10.7 the option disappeared and is no longer supported by Apple in or out of the GUI. Beyond what Apple support it can actually be made to work but not easily. Certainly not for existing users with mature PC profiles. It will almost certainly involve a number of bespoke scripts (some of them complex) which I doubt anyone will give away for free that will (1) actually work for your location (2) be easily supported (3) or won't break on the next update or upgrade. Perhaps you want to use the extra capacity the hardware you have OS X Server installed on? If so it may be simpler if you simply purchased additional storage be it DAS or NAS and use that instead. For your environment use the Mac Server for what it is designed to do instead: mac/ios management and deployment as it will be easier in the long run. Is this a brand new Windows domain with absolutely nothing migrated from an earlier domain? How many mac clients do you have? HTH? Antonio Rocco (Apple Consultants Network)

Hi You could try: chmod -R +ai "user:jsmith allow readattr,readextattr,readsecurity,read,execute,list,search,writeattr,writeextattr,delete,write,append,delete_child,add_file,add_subdirectory,file_inherit,directory_inherit" /Users/xxxx/Documents/Permissions Test The above is all on one line and must be run as root. I know you know this but I hope the following might help others? Firstly it’s important to understand that Macs are first and foremost a ‘nix’ box and secondly I’m hoping the brief explanation that follows of the permission models available on the platform might help you find the correct combination? There is the standard POSIX (because it’s fundamentally a ‘nix’ OS as explained earlier) permissions and ACLs or Access Control Lists. ACLs are similar but not exactly the same as what you see on the Windows platform. ACLs propagate wheras POSIX don’t. Both work in conjunction with each other although ACLs do supercede/override POSIX. The order in which the permissions models are applied is also important. For example an ACL deny will override a POSIX allow as it will always be listed first (as you view it) using the Finder. It’s best to see what permissions are applied using the command line (rather than the Finder) and the basic command that will allow you do this is ls. For example: ls -lae /Users/whatevertheusernameis you can compare the output of: ls -lae /Users to the one above and you should see the @ symbol beside username. In Terminal standard POSIX will always look like this: drwxr-xr-x 7 username staff 12292 4 Dec 13:24 . Whereas the same thing with an ACL applied will look like this: drwxr-xr-x+ 47 username staff 1598 4 Dec 13:24 . 0: group:everyone deny delete You can’t eliminate POSIX permissions as all the config files and directories in /etc and /var rely on them. Both of these (and others) are hidden from the GUI. Without these files/directories and associated permissions the platform simply won’t work. Furthermore few of these files/directories are involved in presenting the shiny GUI the platform is known for. It’s OK practice to apply permissions using the Finder (on the client OS only) which accesses the POSIX model only. To apply ACLs you need to use the command line. Once you use ‘chown’ and/or ‘chmod’ in the appropriate format you’ll see another username is applied with the ‘custom’ flag alongside. This is by design and is normal behaviour. HTH? Antonio Rocco (Apple Consultants Network)

Hi Seawolf gives good solid advice (as usual) and Casper is certainly something you should consider along with the other suggestions made. There's no requirement for the OS X Server version to be the same as the client OS. A good 'general rule of thumb' for OS X is client OS to be either one lower, the same or one newer than the server version you have. In an ideal world you should try and keep everything consistent. One more thing you may want to consider is whether or not there's a real 'need' to upgrade at all? What is 10.9 going to give you that you don't already have? The old adage of "if it's not broke, don't fix it" may still apply for your situation. It's also good policy to hold off upgrading until the OS becomes more stable as later system updates tend to be more reliable. Antonio Rocco (Apple Consultants Network)

Hi It's not recommended using ARD to do this on one mac let alone the number you have. Remember this is a full OS upgrade and not an update. However you could copy the Mavericks installer using the Copy feature in ARD to all 200 iMacs over your network. This has its drawbacks as apart from the obvious impact on your network you'd still have to 'touch' all 200 iMacs in some way to start the upgrade. Either by logging in locally on each one or by sending a series of unix commands wrapped in a script to set the ball rolling. A better way would be to use a deployment tool such as NetInstall, DeployStudio, Munki etc as the other poster has alluded to. If you have OS X Server on your network use it. If you don't then really consider getting it. HTH? Antonio Rocco (Apple Consultants Network)

Hi The error you see is usually associated with trying to write Managed Preferences (or MCX) to an Active Directory Group. When viewing the Active Directory node/directory in WorkGroup Manager you have read only access. Another possibility is DNS (as always). Check the server can resolve itself on both forward and reverse pointers. You should also try and avoid the use of .local for the domain suffix. I should point out it's not impossible to work with .local although it's better if you avoid it if you can. It can be made to work but don't be surprised if you see problems. Antonio Rocco (ACSA)

Hi I've used both GlobalSan and ATTO iSCSI initiators for the Mac and they both do the job as you'd expect. My own personal preference was GlobalSan simply because it was free at the time I used it. HTH? Antonio Rocco (ACSA)

Hi Not knowing exactly what it is you're trying to do but guessing from the little you've provided a couple of things appear to be not quite right to my untrained eye. For example /Volumes/Prefs seems to indicate a local hard drive named Prefs? For me that would be an odd name to call the hard drive? Usually you would leave the hard drive at its default (Macintosh HD) or use some other consistent and logical name. Or perhaps what you really want is the shared directory called Prefs that exists on a Windows Server called ncc-sharedspace to mount on a mac's desktop once the correct authentication details are given? In that case you would use the full path to that directory instead: /Network/Volumes/ncc-sharedspace.whatever/Prefs. Another aspect of the script which may cause it to fail is (as ever) DNS. Although your location might be fine unfortunately some schools idea of DNS and what it is and how to use it falls far short of what it should be. Whatever is the case it's a good idea to double-check it just in case. Are you sure that the mac(s) in question can resolve ncc-sharedspace to a logical IP address? In other words is your DHCP service handing out the correct search domain suffix to allow proper forward and reverse name/IP address resolution? Launching Terminal on any mac and issuing 'ping ncc-sharedspace' should return the correct IP address for that server. If it does not then have a look at your DHCP service and make sure it's giving out the correct domain information to your nodes. If I've guessed correctly regarding the reason for your script then I have to ask why? If all you want to do is mount a windows based share on a mac using an active directory account's credentials, you can do so by simply applying a managed preference policy using either MCX (via WorkGroup Manager) or xml plist using Profile Manager. HTH? Antonio Rocco (ACSA)

Hi You're going to struggle getting OS X Server (and probably any other 3rd-party Server OS?) to re-share a share or shares that are controlled by your DC IMO. In my experience WebDAV works 'best' if it's being offered by OS X Server. However seeing as the home folders are part of your AD environment it makes sense to leverage WebDAV via IIS. This I've done at a number of sites and . . . . . it works well! To set up IIS and the WebDAV module/add-on should not take more than 30-40 minutes. You may have to restart the DC afterwards which probably takes the lion share of the total time taken to set it up. HTH? Antonio Rocco (ACSA)

Hi I have had iMovie working successfully in a networked environment (Open Directory and/or Active Directory) at a number of sites. Perhaps there's something about your network and/or your configuration that is not quite right? Contact me privately if you wish and perhaps I may be able to help? Antonio Rocco (ACSA)

Hi Your post heading 'Active Directory Authentication How to' has nothing really to do with what you're really asking. Apple already provides a built-in tool (Active Directory plug-in in the Directory Utility application) for identifying, authenticating and authorizing users existing in an active directory database using their account credentials when logging into a non-Microsoft operating system. And that's the key to beginning to answer your real question which is about management of non-microsoft operating system workstations using the global policy management console. Micosoft's GPOs where only ever designed to be applicable to Microsoft operating systems. To begin to apply them to something else takes a major effort as well as a deep understanding of the core technologies involved. No offense intended but this level of expertise goes beyond what most school network administrators have. Besides their salary may not begin to cover it either! Even if you've gone to the effort of altering your Active Directory schema (a schema is a set of rules that govern the behaviour of the database it's applicable for) to accommodate Mac OS X you'd have no guarantee the next Microsoft Service Pack or update won't undo the 3-5 days of work you've done. Of course if money is a problem then altering the schema is the 'cheapest' way of doing it. In most people's opinion it's far better to incorporate and utilise an extremely cheap Server App (£13.99) that can be ran on any current Mac hardware. Alternatively what most people go for is a MacMini Server. It has a small form factor, it's cheap and has the Server App included. The Open Directory schema (apple's equivalent of AD) is much, much smaller and won't take up a lot of hard disk space. From there all that's required is the amount of time it takes to 'learn' the software and OS. You'd have to do half of this work anyway if you're considering to or have already deployed apple hardware in your windows network infrastructure. If money is not an object some will consider using a 3rd-party helper application. This is installed on your Windows Servers and it acts as an 'overlay' for the more dominant and much larger Active Directory schema. The helper application takes the burden of mapping object classes and values from one schema to another out of your hands and does it all for you. Some of the most popular (and expensive) are Caspar, Centrify and Likewise. There are others which you can google for yourself. Your final question ' . . . is this the case or is the person telling me this doesn't know?'; I'd say the person has it about right. HTH? Antonio Rocco (ACSA)

@macboy81 Stating "all Intel based processors" is potentially giving out the wrong information. The early model Intel iMacs (any 2006 model) came with Intel Core Duo and Intel Core 2 Duo Processors. Neither of them support Mountain Lion. Any of the 2006 MacMini model came with Intel Core Solo or Core Duo processors. Neither of those support Mountain Lion either. Slightly different situation for the laptop range with far too many variables to list here. For those options you may find it useful to download Mactracker (mac or pc) and you'll have all the information you need regarding any mac hardware and software going right back to the beginning. @edie209 Please check your information again regarding the 1.58Ghz processor. I can't find any mention of MacMini hardware that came with that processor configuration. The closest intel MacMini model I can find is the early 2006 1.5Ghz Core Solo or 1.66Ghz Core Duo. The MacMini models available prior to that model were non-Intel ones and topped out at OS X Leopard (10.5). Perhaps this is the one you mean? Later 2006 intel models shipped with the 1.66Ghz or 1.83Ghz Core Duo processors. Antonio Rocco (ACSA)