Archive | April, 2016

Apple Configurator 2 Workflow

28 Apr

My Workflow:

 

1) Restore/Update a device

2) Prepare your device to a supervised state

3) Install any or all applications that you need for your backup

4) Apply application settings within the apps themselves if needed

5) Apply desired settings and restrictions as needed

6) Back up your supervised device

7) Build your blueprint (in no particular order): Modify device name and wallpaper as desired, add apps, add profiling, and set your blueprint to restore from the backup that you created.

 

Applying a blueprint that has supervised backup incorporated into it to an unsupervised device will make all subsequent devices supervised, with all of your settings intact.  During the process to apply the blueprint you’ll be prompted to restore and supervise devices.

 

Keep in mind that you can only create one backup from a specific device.  If you need to make a different backup you’ll need to grab a different device to do it. Good news is that you can apply a backup to a different device, modify the backup on that second device, and save it as another backup.

Open LDAP not installed

27 Apr
apt-get install php5-ldap

Allow any file upload WordPress

26 Apr

So today I built a profile management server which is basically wordpress running on the excellent turnkey appliance, to get the .mobileconfig profile payloads uploaded I needed to edit my wp-config php file.

To do this connect via webmin or ftp, browse to your config file and add the following line below 🙂

Allow All File Types

There are two ways to override this. The easy way is adding the following line into your wp-config.php

define('ALLOW_UNFILTERED_UPLOADS', true);

Allow Specific File Types

The other way is to add custom WordPress hook in your themes functions.php file

add_filter('upload_mimes', 'custom_upload_mimes');
function custom_upload_mimes ( $existing_mimes=array() ) {
 // add your extension to the array
 $existing_mimes['deb'] = 'application/x-deb';
 // add as many as you like
 // removing existing file types
 unset( $existing_mimes['exe'] );
 // add as many as you like
 // and return the new full result
 return $existing_mimes;
}

The second method is better because you can restrict only the file types you want, but if you have site where your publishers upload may types of document you can disable the restriction from wp-config.php

Munki Setup

22 Apr

If you haven’t yet used Munki its an excellent open source tool for software/profile deployment

Below is quick guide on how to get up and running on Yosemite Server, full credit to the awesome Github community and OSXDominion along with my own notes 🙂

 

Setting Up Munki With OS X Yosemite Server

There are many ways to set up Munki, since it’s just a webserver. TheDemonstration Setup is a great way to get started, but doesn’t list the steps for setting up OS X Server. A lot of new Munki admins (or generally new Munki admins) may have an OS X Server they have access to, but not other web servers, so a guide to getting started with the latest version of OS X Server (as of writing time, that’s Server 4, on Mac OS 10.10.2 Yosemite) may be helpful.

This is all assuming you’ve got Server.app set up and running.

If the Websites service in Server.app is running, turn it off first.

The first steps are to create the Munki repo in the location that Server 4 uses to store website data:
mkdir /Library/Server/Web/Data/Sites/Default/repo
mkdir /Library/Server/Web/Data/Sites/Default/repo/catalogs
mkdir /Library/Server/Web/Data/Sites/Default/repo/pkgs
mkdir /Library/Server/Web/Data/Sites/Default/repo/pkgsinfo
mkdir /Library/Server/Web/Data/Sites/Default/repo/manifests

Change permissions to make sure it’s accessible:
chmod -R a+rX /Library/Server/Web/Data/Sites/Default/repo

In the Server.app Websites pane, edit the “Server Website” (port 80) settings:
Next to “Redirects”, click “Edit…”, and remove the only redirect (which automatically redirects port 80 to port 443 traffic). It should look like this:
Screen Shot 2015-02-18 at 8.42.17 AM

Next, click “Edit Advanced Settings” and check the box for “Allow folder listing” (just for now – it’s easier to visually test this way):
Screen Shot 2015-02-18 at 8.42.13 AM

Turn the Websites service on.

Open up Safari, navigate to:
http://localhost/repo/

You should see a page like this:
Screen Shot 2015-02-18 at 8.37.41 AM

If you can get to this point, you’ve done the website setup work. Now you can go to the next section:
https://github.com/munki/munki/wiki/Demonstration-Setup#populating-the-repo

Once you’ve populated the repo, you can set up a new manifest called “test_munki_client”. Follow the instructions exactly:
https://github.com/munki/munki/wiki/Demonstration-Setup#creating-a-client-manifest

Go through the Client Configuration section:
https://github.com/munki/munki/wiki/Demonstration-Setup#munki-client-configuration
Here, you need to do two things on your OS X client.

If you are testing this on the OS X Server itself (i.e. you are only using one machine total), do this:
sudo defaults write /Library/Preferences/ManagedInstalls SoftwareRepoURL "http://localhost/repo"
sudo defaults write /Library/Preferences/ManagedInstalls ClientIdentifier "test_munki_client"

If you are testing Munki on a different client machine from the server, do this:
sudo defaults write /Library/Preferences/ManagedInstalls SoftwareRepoURL "http://ip_or_domain_name_of_server/repo"
sudo defaults write /Library/Preferences/ManagedInstalls ClientIdentifier "test_munki_client"

And then finally you can check to see if Munki behaves as you’d expect:
sudo /usr/local/munki/managedsoftwareupdate -vv

Populating the repo

We now have a working Munki repo – but it’s completely empty and not useful at all. So let’s start to populate the repo.

We’re going to use some tools distributed with munki to import packages into our new Munki repo. Download the current munki installation package at https://github.com/munki/munki/releases/latest.

Install the Munki tools by mounting the disk image and double-clicking the Installer package and installing like any other package. A restart is required after installation.

The tools you’ll use as an administrator are available from the command-line, and are installed in /usr/local/munki. This location is not in the standard search path, so you’ll need to either add this directory to your search paths, or be sure to type the full path when invoking these tools.

The tool we will use to import packages into the munki repo is called munkiimport. We need to configure it before we can use it – telling it where to find our repo, among other things.

bash-3.2$ /usr/local/munki/munkiimport –configure
Path to munki repo (example: /Volumes/repo): /Users/Shared/munki_repo
Repo fileshare URL (example: afp://munki.example.com/repo):
pkginfo extension (Example: .plist):
pkginfo editor (examples: /usr/bin/vi or TextMate.app): TextMate.app
Default catalog to use (example: testing): testing
We are first asked for the path to the Munki repo, and since we set one up at /Users/Shared/munki_repo, that’s what we enter.

Next, we are asked for a repo fileshare URL. This is used when the repo is hosted on a remote file server, and this would typically be an afp:// or smb:// URL specifying the share. Since we’re hosting the repo on the local machine, we’ll leave this blank.

We are then asked to specify an extension to append to the name of pkginfo files. Some admins prefer “.plist”, some prefer “.pkginfo”. Personally, I just leave it blank – Munki doesn’t care.

Next, you are asked for an editor to use for the pkginfo files. If you like command-line editors, you can specify /usr/bin/vi or /usr/bin/emacs for example. If you, like me, prefer GUI text editors, you can specify a GUI text editor application by name (but be sure to include the “.app” extension). I picked TextMate.app, but you could choose TextWrangler.app, BBEdit.app, or even TextEdit.app.

Finally, you are asked for the default catalog new packages/pkginfo should be added to. We’ll use a “testing” catalog for this.

Further reading here

Binding Macs to AD – Troubleshooting

21 Apr

https://community.spiceworks.com/topic/618936-bind-mac-os-x-10-9-5-to-ad-server

 

 

Home Directories showing as Documents

21 Apr

Another workaround for the lovely “documents” issue is……

  1. Navigate to share eg \\Server\Users
  2. Right click on column SIZE
  3. Click on More at the bottom
  4. tick Filename

Index Network Drive – Spotlight Mac

20 Apr

Nice article which still works for El Capitan

Papercut and AD

20 Apr

Good read if you are new to Papercut and AD

iBooks Frozen

19 Apr

If iBooks is stuck open on the title page or any other page, go to the iTunes App and download any free book and click on READ. The book that is stuck open will close and the free book you downloaded will open in iBooks

RAGE.

.local to Office365 SSO

18 Apr

How to prepare a non-routable domain (such as .local domain) for directory synchronization


APPLIES TO: Office 365 Admin
When you synchronize your on-premises directory with Office 365 you have to have a verified domain in Azure Active Directory. Only the User Principal Names (UPN) that are associated with the on-premises domain are synchronized. However, any UPN that contains an non-routable domain, for example .local (like billa@contoso.local), will be synchronized to an .onmicrosoft.com domain (like billa@contoso.onmicrosoft.com). If you currently use a .local domain for your user accounts in Active Directory it’s recommended that you change them to use a verified domain (like billa@contoso.com) in order to properly sync with your Office 365 domain.

What if I only have a .local on-premises domain?

The most recent tool you can use for synchronizing your Active Directory to Azure Active Directory is named Azure AD Connect. For more information, see Integrating your on-premises identities with Azure Active Directory.

Azure AD Connect synchronizes your users’ UPN and password so that users can sign in with the same credentials they use on-premises. However, Azure AD Connect only synchronizes users to domains that are verified by Office 365. This means that the domain also is verified by Azure Active Directory because Office 365 identities are managed by Azure Active Directory. In other words, the domain has to be a valid Internet domain (for example, .com, .org, .net, .us, etc.). If your internal Active Directory only uses a non-routable domain (for example, .local), this can’t possibly match the verified domain you have on Office 365. You can fix this issue by either changing your primary domain in your on premises Active Directory, or by adding one or more UPN suffixes.

Change your primary domain

Change your primary domain to a domain you have verified in Office 365, for example, contoso.com. Every user that has the domain contoso.local is then updated to contoso.com. For instructions, see How Domain Rename Works. This is a very involved process, however, and an easier solution is to add UPN suffixes, as shown in the following section.

Add UPN suffixes and update your users to them

You can solve the .local problem by registering new UPN suffix or suffixes in Active Directory to match the domain (or domains) you verified in Office 365. After you register the new suffix, you update the user UPNs to replace the .local with the new domain name for example so that a user account looks like billa@contoso.com.

After you have updated the UPNs to use the verified domain, you are ready to synchronize your on-premises Active Directory with Office 365.

Step 1: Add the new UPN suffix

  1. On the server that Active Directory Domain Services (AD DS) runs on, in the Server Manager choose Tools >Active Directory Domains and Trusts.

    Or, if you don’t have Windows Server 2012

    Press Windows key + R to open the Run dialog, and then type in Domain.msc, and then choose OK.

    Choose Active Directory Domains and Trusts.

  2. On the Active Directory Domains and Trusts window, right-click Active Directory Domains and Trusts, and then choose Properties.

    Right-click ActiveDirectory Domains and Trusts and choose Properties

  3. On the UPN Suffixes tab, in the Alternative UPN Suffixes box, type your new UPN suffix or suffixes, and then choose Add > Apply.

    Add an new UPN suffixChoose OK when you’re done adding suffixes.

Step 2: Change the UPN suffix for existing users

  1. On the server that Active Directory Domain Services (AD DS) runs on, in the Server Manager choose Tools >Active Directory Active Directory Users and Computers.

    Or, if you don’t have Windows Server 2012

    Press Windows key + R to open the Run dialog, and then type in Dsa.msc, and then click OK

  2. Select a user, right-click, and then choose Properties.
  3. On the Account tab, in the UPN suffix drop-down list, choose the new UPN suffix, and then choose OK.

    Add new UPN suffix for a user

  4. Complete these steps for every user.

    Alternately you can bulk update the UPN suffixes by using PowerShell.

You can also use Windows PowerShell to change the UPN suffix for all users

If you have a lot of users to update, it is easier to use Windows PowerShell. The following example uses the cmdlets Get-ADUser and Set-ADUser to change all contoso.local suffixes to contoso.com.

See Active Directory Windows PowerShell module to learn more about using Windows PowerShell in Active Directory.

  • Run the following Windows PowerShell commands to update all contoso.local suffixes to contoso.com:
    $LocalUsers = Get-ADUser -Filter {UserPrincipalName -like *contoso.local'} -Properties userPrincipalName -ResultSize $null
    $LocalUsers | foreach {$newUpn = $_.UserPrincipalName.Replace("contoso.local","contoso.com") $_ | Set-ADUser -UserPrincipalName $newUpn}