AntonioRocco

Renaming your server from MacServer.local to MacServer.org won't work as this is its Bonjour name and you can't edit the .local suffix for Bonjour. It will always append this to whatever you decide its name is going to be. Its FQDN is another matter and that's what you should be changin because your domain has changed. Make no mistake - just as in AD - changing your domain will have a major impact on your Macserver, OD and in turn Profile Manager and everything else that depends on them. In brief: 1) No. Its your DNS you have to change not bonjour; 2) Yes; 3) Yes. Once you reset your Macserver's hostname you'll have to start again with Open Directory and by implication Profile Manager which, in turn, will change your APNS certificate. If it was me I would start again with the server and the whole stack that you're going to need. My 2p. Antonio Rocco (ACSA)

Can you trace the connection from your external IP to anything on the private side of your firewall? Can you telnet (or portscan) externally and see if there are any open ports? Do you have anything on your private network accessible externally? I'm asking because apart from what PM and APNS requires there shouldn't be anything else other than what your windows servers are providing. Perhaps that's where the attack is? Botnets invariably target the usual ports - email/web/smb etc - and its doubtful you're mac server is handling any of those services in a school environment.

Sounds strange seeing as you haven't installed it. Sounds like a scam/scare-ware? How were you notified? A pop-up when browsing the internet on the server itself by any chance? I would not browse the internet on any server regardless of platform. Can't imagine how anyone could get details of your mac server if it was by email notification? Before installing Drupal you need to install MySQL. Unless you really know what you're doing then the default install location for this would be /var. To list the contents of /var launch Terminal (in the Utilities folder) and type: ls /var If it's installed you should see a folder name mysql. If there was a chance that someone else other than yourself had access to your server then you can use the history command to see all the commands that have been issued on the mac server. Look for an obvious reference to it there. MAMP, Drupal etc have never been part of any stock/factory OS X install AFAIK. SQL on OS X server is now PostGreSQL. It's what Profile Manager/Wiki uses for its database. Apache binaries have been part of every OS X since at least 10.3 server or client. Basically you can turn any mac into a web server using the command line only. Apple provided a simple GUI for it in their server releases only. Hope this helps? Antonio Rocco (ACSA)

I've seen the "failed to enumerate . . ." error message before and it turned out to be bad installer media. If you contact Apple they may send you a replacement? You've nothing to lose if you try. Another possibility is which type of 10.6 installer are you using? If you're using a hardware specific one (grey in colour) then it probably will fail because the hardware is not what the disk is expecting. You'd need the generic 10.6.3 installer which has a Snow Leopard on it. One further possibility is the processor upgrade may not have taken as well as you'd hoped. I would strip it down again, make sure you really clean the heatsink, put it back together again and zap the PRAM (option+command+p+r simultaneously) just once when switching it back on. Hope this helps? Antonio Rocco (ACSA)

Not doubting what you're saying but are you sure you're using OD and not AD in some way? I'm asking because the screen grabs looks like your using the server's bonjour name as well as the path to users' homes looking suspiciously like what you'd have in AD, ie: nested folders. A typical OD environment would have very flat paths to users' homes. If you're not using bonjour or you've not based OD around .local then I would expect to see something like hallx-osx.yourdomain.internal/Group203 in the url=smb:// path instead of what you have. Presumably AD is providing DNS & DHCP and the DNS service is not enabled on your mac server? If you have used .local for your internal DNS domain that will explain why users experience the unreliability you see. No real way around this unless you rebuild the domain. If DNS is with AD then that's not a trivial thing to achieve. There are things you can do on the macs to minimise this (altering the mdns timeout value for example) but it won't be a real and lasting fix. If the macs and the OD domain are standalone and not part of the AD environment other than accessing the internet then you can rebuild the mac domain fairly easily and should not cause too much disruption or take as long as it would if it was AD. On a side note that may be of interest, but I'm also an independent Apple Consultant and Systems Engineer of many years experience based in South Yorkshire. Antonio Rocco (ACSA)

Thanks Arthur for suggesting Homebrew and who knows OP may do OK with it? But I have a problem with offering Homebrew and others like it as alternatives, especially to those who profess not to be mac users such as the OP. My view is unless you really know what you're doing, especially when it comes to Terminal, then stick with a packaged app you can find on the App Store. I've been there too many times with those who have come unstuck. The few commands I've listed essentially don't change anything and are Apple installed binarys after all and are not the same as installing Homebrew. Nothing wrong with Homebrew, just me just being ultra-cautious. My 2p.

Not only have Apple removed the open source ftp binary that used to be part of the UNIX sub-system but they also removed the telnet binary as well. Telnet is one I used a lot. My way around this was to copy the telnet binary from a mac with Sierra OS installed to the same relevant location, reboot and things were back to normal. I don't use ftp if I can help it because it's very insecure, even on a local network. But if you're OK with it then there's no reason why you can't copy the ftp binary. Beyond a 3rd-Party utility I don't think there's much else? If you did not know, then binarys on a Mac are stored in /usr/bin. Copying them from a previous OS to High Sierra means you have to disable SIP (System Integrity Protection) or copying them to the local bin location /usr/local/bin instead. Disabling SIP is up to you but it's the first thing I do as it hobbles troubleshooting. Using cp -R to copy the binary preserves root user permissions. You can verify the copy has been successful by accessing the manual pages for the binary, man ftp should do it but if you want to look at it in an easier-to-read way this link may be better: https://ss64.com/osx/ftp.html

The problem with institution based courses (Amsys, Apple etc) is they're general at best and don't cover in any real detail the information you need for your particular requirements. Every school is different and over the years my advice has always been to look for training specific to your environment, hardware and needs. I'm not touting for business but it is something I offer to those who are interested.

Have a look in the top level Library folder. If you see a Managed Preferences folder then the profiles will be stored there. Deleting the whole folder and rebooting is the way to go.

Does this happen regardless of which workstation the affected user logs onto? Or is it always the same workstation? I'd imagine with local homes it would make sense to let users use the same workstation. If the last two questions are true then log in as the local admin and issue this command from terminal: dsconfigad -show If its OK post back the results.

I did this once a long time ago, 2003 Server I think? As I remember you had to make sure the mac workstations themselves (not just users) were trusted (or appeared in the relevant OU) in the second domain. As OS X is a non-Microsoft OS you may have to jump through a few more hoops than you would normally do if the OS was native. Probably not applicable in your environment but something you can quickly check. Other possibilities you could look at is if the the tick box for "Allow Authentication from All Domains" is checked. On an affected Mac what does the following Terminal command show? dsconfigad -show

The writing has been on the wall since 2011 when Apple discontinued the XServe in January of that year. That's 7 years. Apple dropping the hardware meant they would be dropping the Server OS not too long afterwards. The last decent server version was 10.6. Since then it's been a painfully half-baked transition to what there is now. I have to agree with Brimstone. There are and have been better management tools available for a long while now although it will be interesting to see what is new in the Server App's replacement. Antonio Rocco (ACSA)

Just for clarification and also to help in your understanding of how 'macs' work in an AD environment. There are a number of ways of doing this but your Mac workstations don't have to be 'attached' to your Mac Server. With Profile Manager you enrol them and then apply the Mac equivalent of global policies either to the workstations themselves, and thereby applied to users logging onto those workstations, or to a group, created in Profile Manager that has your AD Groups nested within. For this to work you need to join/bind the Mac Server to the AD Domain in the same way your would Mac Workstations. Although not impossible it would be unusual for Macs to login to AD via scripts. The OS has a built-in plug-in that is used for binding/joining the mac hardware to the AD Domain in a similar (not exactly the same) way that you join your PCs to the same domain. Hopefully this may help you further?

My general 'rule of thumb' over the years has always been one OS version older and newer than the Server OS version. However I have managed clients 2 versions older than the server without too much trouble. Managing Macs with Profile Manager has been around since 10.7 so any version after that, in theory, should be OK. I would stop at Mavericks if I was you though, and try if out first before rolling it out wholesale. When comparing the user experience don't be surprised if certain things won't work or don't work as well as they do on workstations with latest OS installed. As every your mileage may vary. Antonio Rocco (ACSA)

As you've seen Migration Assistant (for server or client) takes a while when large amounts of data are involved. If you wait long enough (I can't say how long) it will eventually do it. This, unfortunately, is where I have a problem with it, because in my experience, the longer it takes the more likely you'll get errors and the likelihood for transferred data to be partially skipped increases. What I would do and have done many times in the past, because it's quicker, is to bypass the migration assistant altogether. Set up the new server as you've already done, prepare the shares as you want them and run the following command on shares (stop the sharing service first) on your old server: sudo chmod -R -N /pathtoshare I would run the command a couple of times to be on the safe side. Do it for all the shares involved if there are more than one and don't ever run the command on the top level of the system/boot drive. Finally target disk mode the olde server to the new one. When the old server appears on the desktop, navigate to the data and start copying it over. When the data has been copied, apply the desired permissions to the data and propagate. The instructions above are only for shared data and not for user home folders. I've assumed user home folders are with your AD. If your environment is different to the usual then don't follow any of the above and post back with more details. Hopefully this may help? Antonio Rocco (ACSA)

I've used it but it wouldn't be my first choice. For your needs though it probably fits the bill. For me it has performed well but I'd recommend a minimum of Gigabit to Desktop for the network and at least double the storage capacity for the total amount of disk size the clients have. For example 4 client Macs each with 500GB hard disk totalling 2TB means you should set aside 4TB for the backup drive. Obviously I would add another drive of similar size that the first back up can be backed up to for offsite storage. I'm assuming this would be important for you? As for impact it depends on how you've segmented your network. If you're using Class C's everywhere with only necessary traffic between as well sd a decent backbone there should be relatively little impact although YMMV. It will be interesting to see if there are others here who have used it, or are using it and what their experiences of it are. On a final note and not being sure which version of OS X Server you have, you should be aware the service is no longer in the Server.App in High Sierra. Apple have moved it to the Sharing Preference Pane in System Preferences. Setting up Time Machine Server is fairly simple as this MacWorld article explains: https://www.macworld.com/article/3130110/servers/turn-up-the-time-machine-service-in-macos-server.html However the best resource for all things Time Machine was James (Pondini) Pond's definitive website: Site Suspended - This site has stepped out for a bit Unfortunately the site has been down for a while but it may be worth your while to monitor it and see if it comes back up again. Pondini passed away 4 years ago. Hopefully this may help? Antonio Rocco (ACSA)

You're welcome! Machine spec you've given is under-powered in my view for iMovie let alone FC. I know it's not ideal but it may be better if you uninstalled those applications and installed them on another suite of macs instead. Video editing is in a league of its own when it comes to media and really should be dealt with differently. If this can't be done then educating users to quit out of applications when not using them may 'fix' this in the short term. It's going to be difficult but certainly worth a try? This may or may not help but I recently set up a video editing suite at a college where I disabled all unnecessary apps prior to deployment leaving only the apps necessary for the students to do their work active. Similar spec hardware to yours. Just my opinion but it's something you could try and look at moving forwards. Antonio Rocco (ACSA)

Sorry to be the bearer of potentially bad news but in my experience this could be a number of things. One possible 'quick fix' is the delete the com.apple.loginwindow.plist from the Preferences folder. You'll find this in the top level Library folder. Seeing as it's only a couple of Macs this is an easy thing to do either locally or by sending a Terminal command using ARD. When setting a policy for the login window I tend to 'bake it in' or use a script applied via DS. Just some friendly advice but I would consider carefully the school's approach to mac management? As it's only the two macs you could shine a torch on the screen when the problem happens as it could be an intermittent hardware issue? If you see an image behind the black screen then an Apple Repair Centre should be able to run tests to confirm this one way or another. Are the macs affected laptops or desktops? I ask as laptop inverter boards are not that expensive. If none of the above help then how old are the macs? How much RAM? I ask because I think you may be looking at advising/educating everyone on how FC works and the best way to use it in an educational environment. I've emphasised this last point as most people who work in educational institutions only have experience of FC in a standalone/at home environment and don't fully grasp the complexity of using it in a large Active Directory network. For example a 4GB project in iMovie (with FC the processing/disk/network overheads can go up, a lot) can take 3-4 hours to render. Once rendered it can take a further 40-60 minutes to write/export. This additional time is taken up with background processes which can cause issues on logout, especially the sort that you see. If you've ProTools installed and possibly Adobe's suite of programs (usually the case as it's all media isn't it?) as well, then these problems can be compounded. When contemplating Macs or PCs for Video editing, my advice is, usually, to set aside a specific suite with the fastest network possible; work locally; save often; use local accounts and keep the macs 'lean'. By lean I mean don't install or use anything else apart from FC. If the students want to do a bit of internet, email or Word, direct them to another terminal, PC preferably, instead. Of course the advice does depend on budgets and other factors etc and the above is only what I'd call ideal. Hope this helps? Antonio Rocco (ACSA)

Mail.App like any other Mail application uses the usual standard ports. SMTP port 25, 143 for IMAP and so-on. If your firewall is blocking these, which is more than likely in an educational institution, then that could be the reason email isn't working? Other possibilities could be User/Group ACLs coming from your AD are not working as they should and possibly blocked certificates? SSL certificate-based email ports are 993 and 995. There's also the alternate submission port 587. Here's the link for Apple's KB for all their ports: https://support.apple.com/en-gb/HT202944 Antonio Rocco (ACSA)

You can't install DMGs as these are disk images. Within the DMG should be an installer file. Could be a PKG or MPKG which can be used with Munki. It could also be a proprietary installer file which may not be a PKG or MPKG. Your problem then is to create a PKG from that installer file and the other bits and pieces that installer needs. You can use the command line to create PKGs or 3rd-Party software such as Iceberg or Packages. You may struggle with either of these methods as they're not that intuitive in which case you have to think of another way of installing what's on the DMGs. It's possible the DMGs contain standalone applications such as Firefox. If that's the case you can simply copy the application to target macs using ARD's copy feature instead.

Option click the Go Menu and it will appear. Tip: Once it appears you can drag it to the sidebar so it's permanently available for that user account. Antonio Rocco (ACSA)

@ XiJ Yes you're correct. OS X Systems Software (server or client) is only licensed to run in a virtual environment on Apple hardware. That does not mean to say it won't run on other hardware although you do so at your own risk and you lose all support if you have a problem. In practical terms it can be difficult to do and if you managed to get installed in a VE on non-Apple hardware it's slow and unreliable. My view is why bother attempting it when any virtualised server software (Apple, Microsoft, Linux etc) runs well on Apple hardware.

In addition to the good points made in XiJ's post it's important to make clear that DeployStudio by itself cannot NetBoot mac clients. NetBoot is a service provided by the Server.App which you will still need regardless of whether you decide to use Profile Manager or not. I have to say in Profile Manager's defence that it is not all that bad once you realise its limitations. Think of it as one corner of a well rounded mac management system that includes ARD, Munki or Reposado, DeployStudio or any one of a number of MDMs available which Apple's Profile Manager is just one of. Although deprecated for a long time now even WorkGroup Manager (although clunky and unreliable on the newer OS) can still be used in a limited way. Antonio Rocco (ACSA)

As mentioned your issue is DNS. Unless you pre-create appropriate A and PTR records for the hostname and IP address reserved for your server, nothing will work, if at all. However it does not end there. You should also avoid the use of .local for the TLD of your domain. If your AD domain is built around this then you will have issues as .local is reserved for Bonjour services (multicast dns) and can't be removed or bypassed as it used to be in earlier versions of the OS. However your mileage may vary? As an example if your domain is some school.local you will have problems. If it's something.someschool.local not so much, or maybe not at all? If it's not using .local then you should be OK? Just as long as the mac server and clients are referencing your DCs as their DNS and NTP servers. I applaud your determination in doing this yourselves but sooner or later you will benefit from some site specific training. Attending Mac specific training courses is fine up to a point but none of them will mention the trials and pitfalls of Active Directory integration in any detail if at all. Finally Open Directory is fundamental to how well Profile Manager works. The two go hand-in-hand and you can't have one without the other. Profile Manager does not work well (if at all) behind a proxy. Hopefully this may help? Antonio Rocco (ACSA)

You should be able to manually enable FileVault for as many users that share those Macs. Just enable it in the relevant part of security preferences pane. Only potential problem I can see is the amount of users you're trying to do this for as well as having sufficient disk space. Its more than possible to script this and make it part of your deployment tool. Alternatively use ARD to send the relevant commands. Consult the relevant command line manual pages for the OS installed on your Macs as it has changed since Mavericks 10.9. In El Capitan and newer its 'man fdesetup'. In Mavericks its 'man fdsetup'. Der Flounder has some useful information relating to it: https://derflounder.wordpress.com/?s=FileVault+2 Antonio Rocco (ACSA)