If you’re running macOS 10.15 Catalina and need to run Microsoft PowerShell to administer Microsoft Office 365 tenants, you can do so using Homebrew on macOS. It takes a bit of massaging, but here’s how I got it working:

If you’d prefer to just install the Xcode command line tools (and not the full 12GB Xcode Developer package), first open terminal on your macOS and run "xcode-select --install” and you will be prompted to download and run the CLI tools.

​Then run the following commands in the Terminal app, one at a time:
brew reinstall python
brew tap homebrew/cask-versions

Then you can test that it's installed by running:
brew cask install powershell-preview

For updates in the future, you can run:
brew update
brew cask upgrade powershell-preview

​macOS device and MDM provider Addigy announced support for tvOS in their MDM offerings earlier this year. 

This article will walk you through installing an MDM profile on a tvOS device, using a macOS device running Apple’s Configurator app, which you can get here:

https://itunes.apple.com/app/apple-configurator-2/id1037126344

To get started, you’ll need to pair your macOS machine to your Apple TV, as follows:

Make sure your macOS device and Apple TV are on the same wireless network.
On your Mac, open the Configurator app, and select “Paired Devices.”
On your Apple TV, select “Settings > Remotes & Devices > Remote App & Devices.”
Choose your Apple TV from the devices list on the Configurator app on your mac, and enter the PIN from your Apple TV.

Download the MDM profile from the appropriate policy from your Addigy installers page.

In the Configurator app, choose your device, and then choose “Profiles” from the left hand side of the Configurator app, choose the option to add a profile, then choose the  .mobileconfig file you downloaded from Addigy.

Once you’ve done that, you’ll see a prompt on your Apple TV asking to confirm the installation of the MDM profile.

With Apple’s server app going the way of the dodo bird, I have been on the lookout for a free software package to run a DNS server on macOS. With the help of Xcode tools and Homebrew, I've found a great solution in dnsmasq.

To set this up, first, install the free Xcode command line tools by running the following command from the Terminal app:

xcode-select —install

And this should prompt you to do the download and install. Then, you can install homebrew by opening a terminal and running the following:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)”

Then install dnsmasq by running:

brew install dnsmasq

The dnsmasq config file will be installed at "/usr/local/etc/dnsmasq.conf”

By default, dnsmasq consults the contents of the “/etc/hosts” file for DNS records, but I’d suggest creating your own separate file(s) to keep your DNS host records. To do this, you need to add a line to the config file (for each file you want to use -- you can have more than one) that contains the path to the file where you’ll keep your records, like so:

addn-hosts=/Path/To/Hosts/File/hosts.txt

And then create the text file, with the path and name you specified above, and add DNS records to the file as follows:

192.168.100.1    host1.domain.test
192.168.100.2    host2.domain.test

With each line containing an IP address, a space (or tab), and then the hostname. In this case, a lookup for host1.domain.test would resolve to 192.168.100.1 for a machine using our dnsmasq DNS server.

To make sure dnsmasq starts automatically at reboot, do the following:

sudo cp /usr/local/opt/dnsmasq/homebrew.mxcl.dnsmasq.plist /Library/LaunchDaemons/
sudo chown root:wheel /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist
sudo chmod 644 /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist

Then you can start dnsmasq with this command:
sudo launchctl load /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist

And stop it with this one:
sudo launchctl unload /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist

In this configuration, dnsmasq will answer dns requests for any records you've created, but will pass requests for machines it doesn't know about up to whatever DNS servers are listed in your Mac network prefs.
​
Good luck!

Getting Windows clients to connect to macOS servers is usually fairly straightforward, but there are a number of issues that can cause problems, and can be tricky to track down. For such scenarios, I’ve put together this list of things to try when you're troubleshooting this kind of situation.

First of all, just having the proper URL to connect to the server is important. So if your server is called “MY-SERVER” and has an IP address of 192.168.1.1, and your share is called “MyShare,” you can format the URL in either of the two following ways:

\\192.168.1.10\MyShare
\\MY-SERVER\MyShare

When you try this and your Windows clients can’t connect to the Mac server, here are a few things you can try:


1. Enable NTLM authentication on your macOS server:

Enable NTLM with:
sudo serveradmin settings smb:ntlm auth = "yes"

If you’re using a very old Windows client version, can also try adding Lanman support, as below:
sudo serveradmin settings smb:lanman auth = “yes”

And you can confirm that the change worked by running:
sudo serveradmin settings smb


2. Add server NetBIOS / workgroup name to authentication credentials:

Depending on the version of Windows you’re using on the client machine, you may need to include the server NetBIOS name (or workgroup name) before the username, separated by a backslash (“\”), as part of the login credentials.

So for username "dave" with NetBios name “MY-SERVER, the full "name" in the login window would look like:

MY-SERVER\dave

You can check the NetBios name of your server with the "serveradmin settings smb” command, and look for the "smb:NetBIOSName” parameter in the output.


3. Allow both NTLM v1 and v2 authentication on your macOS server:

The versions of the NTLM protocol that a Mac server will allow are specified in the following file:

com.apple.GSS.NTLM.plist

Which is located in "/Library/Preferences.”

However, this file doesn't exist by default in a new installation. So in order to enforce this authentication parameter, you need to create the file in that location, with the following contents:
 
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
      <key>NTLMv1</key>
      <true/>
      <key>NTLMv2</key>
      <true/>
</dict>
</plist>

Give the machine a reboot, and this will allow Mac OS Server to accept both NTLMv1 and NTLMv2 authentication.


4. Enable ACL support:

One other handy tip when you’re connecting Windows clients to a Mac server (this time related to authorization and not authentication) is to enable ACL support for the SMB service (as I mentioned earlier this year in this post), which can ameliorate all kinds of permissions issues that plague only Windows machines. You can do this as follows:

sudo defaults write /Library/Preferences/SystemConfiguration/com.apple.smb.server AclsEnabled -bool YES

Disabling ACL’s again (should you need to) can be done like so:

sudo defaults write /Library/Preferences/SystemConfiguration/com.apple.smb.server AclsEnabled -bool NO

After doing either one, I’d suggest restarting the SMB service on your server, as follows:

sudo serveradmin stop smb
sudo serveradmin start smb

After running either of the above, you can re-issue the “sudo serveradmin settings smb” command to make sure the changes took.

Sometimes it can be really handy to have the Xcode command line tools installed on your Mac without having to download and install the entire Xcode package from the Apple App Store first. For example, if you want to use a package management system, such as HomeBrew or MacPorts, you'll need the Xcode command line tools (which is only about 100 MB as of this writing), but there's no need for the entire 4.5 GB Xcode package.

Installing the Xcode command line tools by itself is actually very easy to do, by running the following command in the Terminal app:

xcode-select --install

When you run this command, you should see a Finder dialogue asking if you'd like to download and install the Xcode command line tools. Just follow the prompt and voila! No need to install the hefty Xcode package first.

In macOS version 10.11.x (El Capitan) and later, Apple has removed the "repairPermissions" and "verify" switches from the "diskutil" terminal command. There are still ways to run these two functions, but they are no longer called from within the diskutil command. You can run the "verify" function on a volume with the following command:

sudo /usr/libexec/repair_packages --verify --standard-pkgs /

And you can repair permissions with this one:

sudo /usr/libexec/repair_packages --repair --standard-pkgs --volume /


​ 

This is a quick and easy tip, but also a super handy one, as the macOS is often less than graceful in the way it's able to unmount volumes (or give you useful information when it's not able to!)

To force a volume to unmount, you can open the Terminal application and run this command (of course, you want to replace "Volume_Name" below with your actual volume name:

diskutil unmountDisk force /Volumes/Volume_Name

By default, SMB ACL’s are disabled on Mac OS X Server, and there are many situations where it can be helpful to enable them. To see whether SMB ACL’s are already enabled on your server, you can issue the following terminal command (as always, be sure to make a full backup of your server before making any changes):

sudo serveradmin settings smb

If SMB ACL’s are enabled, you’ll see a line that contains “AclsEnabled = yes” as part of the output. If they’re not enabled, you’ll either 1) not see a line starting with “AclsEnabled” or 2) you’ll see a line that contains “AclsEnabled = no.”

To enable ACL’s you can issue the following command (I’ve tested this on Yosemite 10.10.x running Server app v. 5.0.x, and El Capitan 10.11.x running Server app v. 5.2.x):

To enable ACL’s:

sudo defaults write /Library/Preferences/SystemConfiguration/com.apple.smb.server AclsEnabled -bool YES

To disable ACL’s:

sudo defaults write /Library/Preferences/SystemConfiguration/com.apple.smb.server AclsEnabled -bool NO

After doing either one, I’d suggest restarting the SMB service on your server, as follows:

sudo serveradmin stop smb
sudo serveradmin start smb

After running either of the above, you can re-issue the “sudo serveradmin settings smb” command to make sure the changes took.

Some applications require an older version of the Java runtime environment than the one that ships with Mac OS 10.10.x (Yosemite) and later.

Downloading and installing Java SE 6 runtime (a version that is commonly needed by these older Mac Java apps)  is easy. Apple has left the installer online, which is available for download here:

https://support.apple.com/kb/DL1572?locale=en_US

The LDAP (lightweight directory access protocol) database is an essential part of a Mac Server Open Directory environment. As with any database, it is prone to corruption if the LDAP database server isn’t closed properly, which often happens with system power loss, a disk, process or application crash, or any other kind of improper shutdown.

If you’re seeing the following errors in your Mac server slapd logs, that may be an indication that you need to recover the LDAP database:

PANIC: “fatal region error detected; run recovery”
DB_RUNRECOVERY: Fatal error, run database recovery (-30974)

If you see this error, you can issue the following commands from the Terminal App to recover from the last Open Directory backup (I have tested this on Mavericks 10.9.x, Yosemite 10.10.x, and El Capitan 10.11.x server systems - be sure to choose only one of the two disk permissions repair options below) as with trying anything, be sure to completely backup your system before trying this!)


sudo launchctl unload /System/Library/LaunchDaemons/org.openldap.slapd.plist
(10.10.x and earlier:) diskutil repairPermissions /
(10.11.x and later:) sudo /usr/libexec/repair_packages --repair --standard-pkgs --volume /
sudo db_recover -cv -h /var/db/openldap/openldap-data/
sudo db_recover -cv -h /var/db/openldap/authdata/
sudo /usr/libexec/slapd -Tt
sudo launchctl load /System/Library/LaunchDaemons/org.openldap.slapd.plist