If you've read my previous post on FortiClient, you'll already be aware that I'm a great fan of their top-tier methods for deploying this particular application …

Well, it was only a matter of time before we had to delve deeper in to this topic. Yes, that's right, EMS. Here's to another can of rotting worms.

In this episode of how to rapidly lose more hair, we'll go through packaging and deploying FortiClient EMS 7.x with Jamf Pro.

Create the Installation Package

First up, you're going to need a generated package from your EMS service, which will come as a .dmg.

After finding hidden config files in another application I was packaging, I've learned the hard way to double-check this mounted volume. What do we have?

10244  3 Jun 17:48 .DS_Store
2048  3 Jun 17:48 .fseventsd
266257984  3 Jun 17:48 Install.mpkg
258  3 Jun 17:48 Technical Documentation.webloc
2048  3 Jun 17:48 Uninstall.app
16485  3 Jun 17:48 background.jpg
2048  3 Jun 17:48 fctdata

Looks like we've got a hidden folder in here with a load of executables, so we'll need to include that in the re-package, otherwise I'm sure something will break.

Under fctdata, it looks like we've got our configuration files, so we'll certainly need to include them, too.

All in all, I think it's best we re-package this whole thing to ensure we don't miss anything at all. There are a few ways we can do this, but I'll stick with Composer, as we'll be pushing with Jamf.

As we need to grab some hidden files, we can't just drag and drop, so create a folder within the /tmp/ folder.

sudo mkdir /tmp/forticlient-ems

Now, copy the contents of the mounted DMG over to our tmp directory.

sudo cp -r /Volumes/FortiClient /tmp/forticlient-ems
sudo cp -r /Volumes/FortiClient/.fseventsd /tmp/forticlient-ems

/tmp/forticlient-ems

.fseventsd
Install.mpkg
Technical Documentation.webloc
Uninstall.app
background.jpg
fctdata

Fantastic, that's the contents of the file in the temporary directory. Open this location in finder, and fire up Composer. We can then drag that in to the window in readiness to create a pkg.

We'll also create a postinstall script to run the .mpkg installer.

sudo installer -pkg /tmp/forticlient-ems/Install.mpkg -target /

With that done, we can Build as PKG. Then we need to test it and make sure it installs the application as expected as if we were installing it as the end user.

Testing the Custom Package

For this first bit, we'll keep it simple, sign in to our VM as a standard user, and enter some admin credentials when prompted to install the PKG.

Yep, that worked!

As you can see, it comes with an absolute barrage of pop-ups that a non-admin user is never going to be able to resolve, and the FortiClient tray icon is present.

If we check our FortiClient Console, we can see that it's connected and managed by FortiClient Cloud, and also has our remote access details pre-filled, and is just waiting for our login. Fantastic, that means all the custom settings have worked, too.

That's the easy part, complete. Time to revert the snapshot to our clean working base, and work through the next part. Hiding those pop-ups and pre-approving the bits we need to.

Configuration Profile

With the application installing, let's work on hiding all these pop-ups and allowing permissions to things.

The first helpful link in this section:

Re: “FortiTray” would like to add VPN configurations

Heya, sorry for the late reply, I finally figured this out. To avoid the VPN popup configuration, we set a dummy VPN configuration that will be used by Forticlient on runtime : Nothing else is checked, make sure that the Identifier and Provider Bundle Identifier are set to “com.fortinet.forticlient…

Jamf Natione672e508-80b8-4 New Contributor II

So, first up is removing that "Permission required for VPN" pop up. This requires a VPN configuration profile. Let's create a new Configuration Profile, and set a VPN payload.

Scope it, test it. This removes the VPN pop-up. One down, three more to go. Let's tackle the System Extension warning next.

System Extension

We need to get information about that system extension. The easiest way to do this is to check what extensions are active before, and after manually approving the extension. Don't forget to roll your snapshot back again once you've checked ;)!

systemextensionsctl list
1 extension(s)
--- com.apple.system_extension.network_extension
enabled	active	teamID	bundleID (version)	name	[state]
*	*	AH4XFXJ7DK	com.fortinet.forticlient.macos.vpn.nwextension (1.5.0/B20220228)	vpnprovider	[activated enabled]

Great, now we know what system extension we're approving. Let's add a new payload to our configuration profile.

With that tested, we no longer get the "FortiTray would like permission to create VPN profiles". What's next? Well, all sorts.

Security & Privacy Permissions

Trawling through the Fortinet documentation, I finally found a "Special Notices" section, which provides a list of services that need permissions allowing.

http://docs.fortinet.com/document/forticlient/7.0.5/macos-release-notes/223986/special-notices

Right then, let's get started.

We need to sign our life away for the following components:

• fcaptmon
• fctservctl
• fctservctl2
• fmon
• fmon2
• FortiClient
• FortiGuardAgent

Time to add a new PPPC payload to our configuration profile:

Phew, that was a long one! Here's all of that in a way you can copy.

/Library/Application\ Support/Fortinet/FortiClient/bin/fcaptmon

identifier fcaptmon and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = AH4XFXJ7DK


//

/Library/Application Support/Fortinet/FortiClient/bin/fctservctl2

identifier fctservctl2 and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = AH4XFXJ7DK

//

/Library/Application\ Support/Fortinet/FortiClient/bin/fmon

identifier fmon and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = AH4XFXJ7DK

//

com.fortinet.forticlient.macos.antivirus

anchor apple generic and identifier "com.fortinet.forticlient.macos.antivirus" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = AH4XFXJ7DK)

//

com.fortinet.FortiClient

identifier "com.fortinet.FortiClient" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = AH4XFXJ7DK

You'll notice that fmon2 is missing from this list. Well, it's not. No matter how many times I tried to get fmon2 approved, I received warnings about needing to allow access. Turns out that I actually needed to approve com.fortinet.forticlient.macos.antivirus - not fmon2. Thanks for wasting a week there, Fortinet!

That's our VPN, PPPC, and System Extension pop-ups dealt with. Let's try to tackle that certificate warning.

Certificates

This had me boggled for a few days, until a moment of clarity in the shower (it's where my best thinking happens). Honestly, not sure why it took me this long.

I approved the certificate prompt on the test VM, then exported them from the Keychain.

I found we needed two certificates from here. support.cer, and fortinet-ca2.cer.

As this contains certificates which could be revoked, or need to be changed at different intervals to the other settings, I created a new profile with a Certificate payload.

After testing this, I found I had to restart the machine for the certificate trust to be in place. I added a restart option to the installation policy, and no more pop-ups!

That's two configuration profiles, with a total of 4 payloads between them.

Wrap-up

After endless testing with the VM, I deployed it to a few different machines, across a couple of different macOS versions, to ensure that it behaved as expected.

I HATE anything to do with FortiClient. It's always such a pain.

Let's see what we have for this.

1. A custom package with the contents from the pre-packaged DMG

2.  A computer policy to install the package - scoped to staff machines, and made available in Self Service (don't want to be pushing this out with an enforced restart).

3.  Two Configuration Profiles, scoped to our staff machines.

We can finally move this out of test, and close the job off!

I hope this helped some of you out there.

--

Photo by Shubham Dhage on Unsplash

When it comes to installing applications for end users at scale, especially for those on macOS, not every developer plays the game. The combination of packaging/zipping/goodness knows what is vast.

uniFLOW is no exception when it comes to SmartClient. A .pkg, inside an .iso, with hidden files.

I'm writing this as a reminder on how I did this, as I need to deploy an update to the client.

The first mistake I made, when I did this with the original deployment, was not checking for hidden config files within the .iso (… no words). I was deploying the .pkg and couldn't figure out why the client wasn't connecting to the backend.

On further inspection, there's a ".tenantconfig.plist" file inside the .iso file with the .pkg. Because of course there is.

My next deployment attempt was to pop both these files in to a new .pkg using Composer, and then run a postinstall script to install the .pkg.

sudo installer -pkg /tmp/uniflowclient/SmartClientforMac.pkg -target /

This resolved the issue.

Not rocket science, but as I said, I wrote this to remind myself, and hopefully save someone else 5 minutes.

Photo by Devon Janse van Rensburg on Unsplash

Introduction

Firstly, apologies. I didn't manage to get this post out on Thursday as I had planned. A few things got in the way. I began writing, but didn't finish.

Well, I can't believe we've finally come to the end of this post series. This is the first time I've truly tried to give something back to the MacAdmins and Jamf community that has helped me so much over the years. Without which, most of what I've done would not have been possible.

Adjusting to this role has been challenging. I have never been a true fan of Apple, or their products. I'm still not entirely convinced they have a perfect role within an enterprise style environment, either. However, the ease and speed at which I can deploy iPhones and iPads, and have them under a decent level of management, has been spectacular. And, with Apple heading down this route for macOS devices, there may be a future in it. Especially with declarative management. This post series was a gentle nod to the fact that it seems to be getting closer.

Adjusting to writing these posts has also been challenging, but a great learning opportunity. By the fourth part, I felt I had settled in to the writing a little better. The first three felt, somewhat, rushed in comparison. I've still got a lot that I can improve upon, but that's what it's all about, after all.

Series Summary

If you haven't followed the posts each week, I don't blame you. This will be a great chance to figure out what's been going on, and what was achieved across all of them. I'll provide a link to each post with a short summary.

Part One - Prerequisites and PreStage

Fully Automated Lab iMac Deployment with Jamf Pro & ADE: Part 1 - ASM to PreStage

In this first post of the series, we cover Apple School Manager, Jamf ADE, and the initial PreStage settings.

Tech Talk & Mind DumpsGray

The first post was a boring, but somewhat important part in this series. In it, we lay the groundwork and cover the prerequisites required to make this all work.

The three main components are:

• Apple School Manager
• Jamf Pro
• macOS Big Sur or later

In it, we prepare the workflow to take the device from ordering, to PreStage via Automated Device Enrolment (DEP).

Part Two - From PreStage to Auto Logon

Fully Automated Lab iMac Deployment with Jamf Pro & ADE: Part 2 - PreStage to Auto Logon

In the second post of the series, we cover the creation of scripts, smart groups, policies, and extension attributes for the auto logon stage.

Tech Talk & Mind DumpsGray

This is quite a big part of the project. We cover the creation of Smart Groups, Scripts, Extension Attributes, and Policies.

Using these building blocks, we are able to take a device from the default log on screen of PreStage, and automatically log it in with our newly created account.

Part Three - Preparing for Deployment

Fully Automated Lab iMac Deployment with Jamf Pro & ADE: Part 3 - Preparing for Application Deployment

With most of the basic policies in place, we start creating the foundations for deploying applications using DEPNotify.

Tech Talk & Mind DumpsGray

This one lays the groundwork for part four. Here, we make use of further Smart Groups, Scripts, Policies, Extension Attributes, and DEPNotify.

Part Four - Deploying Applications

Fully Automated Lab iMac Deployment with Jamf Pro & ADE: Part 4 - Deploying our Applications

We make use of Inventory Preload, Smart Groups, and Policies to deploy our applications with DEPNotify.

Tech Talk & Mind DumpsGray

In part four, this is where we really start to bring the whole thing to life, and see the results of all the hard work that was done in the last three parts, making this whole thing possible.

Yet again, more Smart Groups, Scripts, Policies, and one of my favourite features, Inventory Preload.

Part Five - Getting it User Ready

Fully Automated Lab iMac Deployment with Jamf Pro & ADE: Part 5 - User Ready

We take our final step on this fully automated journey, making the device user ready with NoMAD.

Tech Talk & Mind DumpsGray

And finally, part five. This was it. The culmination of months of planning, testing, stress, confusion, and severe hair loss.

We create the final few Smart Groups, Policies, Scripts, and make use of NoMAD, and NoMAD Login to make our device truly user ready.

With all this in place, we can do a full zero touch setup on our brand-new iMac.

• Assign it to our MDM server in Apple School Manager
• Use Inventory Preload to provide Jamf some information
• Plug it in

Once it's plugged in, it will automate its entire setup process, installing all our applications inside 2 hours. Completely ready for use.

As you can see, our ** Lab - Zero Touch - Onboarding - DEPNotify **  ran for 1 hour, 33 minutes, 12 seconds. Sixty-nine minutes of that was Adobe.

Without it, you're looking at a fully managed and useable device within 15-20 minutes. Start to finish.

If you've read this part, you may notice that Office 365 is missing. This was down to a typo in the script of the trigger name. It takes about 5.5 to 8 minutes.

Overview Graphic

Below is an incredibly rough workflow overview graphic attempting to show this whole process. I won't lie, I'm not overly happy with it, but I think it serves its purpose well enough.

A Video Summary

OK, that's enough waffle. What does this actually look like when it happens? Well, here's a video showing the process.

I have trimmed out parts of the video to make it shorter (who wants to watch almost 2 hours of this?).  But the whole process is there. This was not a professional trim job!

Thanks & Contacts

As I mentioned at the start. None of this would have been possible without the incredible communities that I'm a member of. First and foremost, to MacAdmins.org. Their Slack channels provide access to some incredibly talented people who are always friendly and willing to help. There is an absolute treasure trove of information in there if you search for it.

Next, the Jamf Community. If you have a question about something Jamf, it's probably already been answered here in some way.

And also a big thank you to Scripting OSX for the post mentions in the weekly round-up. Seeing that made my day, thank you!

https://scriptingosx.com/

If you want to get in touch with me, you can find me in various places. The MacAdmins Slack for one (#uk)! However, the quickest and easiest place is over on the Fosstodon.org Mastodon instance, or Matrix: @grayw:opensuse.org

The post Photo for this post series was by Quaritsch Photography on Unsplash

Intro

Wow, I can't believe we're here. The final stage of this workflow. All that's left to do is make the device ready for the user. What a journey! If you've made it this far, congratulations. Reading my waffle is not easy. However, if you're just jumping in, you may want to go back and read the other posts in the series - especially the first. There are some prerequisites that you really shouldn't skip. Alternatively, you could wait until Thursday, when a full summary post goes up.

Jamf Deployment Series - Tech Talk & Mind Dumps

Over the course of this blog post series, we will cover the whole process of automating the setup of iMac’s in a multi-user lab environment.

Tech Talk & Mind Dumps

Let's get on with the show.

Previously

In part 4, we covered creating some more Smart Groups, filling out our DEPN script with the rest of the application policies we wanted to deploy, and making use of the Inventory Preload feature.

In this post, we're going to go over the last few lines of our DEPN script to get them into a user ready state.

# ## Send updated inventory for Smart Groups and check for any remaining scoped policies
DEPNotify "Command: MainText: Installing Room Specific Requirements"
DEPNotify "Status: Update inventory record."
jamfCommand recon
sleep 3
jamfCommand policy
sleep 3
/usr/bin/defaults write /Library/Preferences/co.uk.grayw.blog onboardingComplete -string "Complete"
#
## Prepare for Final Usage
DEPNotify "Status: Install NoMAD & NoMAD Login"
jamfCommand labzt-nomad
DEPNotify "Status: Removing Auto Logon"
jamfCommand labzt-remove-autologon

Let's work from top to bottom.

Onboarding Complete

There are certainly improvements we could throw in here, and perhaps this isn't the perfect method, but I want to know when a device has reached the end of this process. To do that, I'm going to write out to a plist file.

/usr/bin/defaults write /Library/Preferences/co.uk.grayw.blog onboardingComplete -string "Complete"

There's a reason I'm not doing this before the recon command. We don't want other policies running during that jamfCommand policy line, and interfering with our onboarding process. We'll let it get those on the next check in once we're done.

To make scoping of generic policies easier, we're going to make use of this by creating another Extension Attribute.

Extension Attribute

We'll create the Extension Attribute as a script that looks like this.

#!/bin/bash

status=`defaults read /Library/Preferences//Library/Preferences/ac.uk.grayw.blog onboardingComplete`
if [ "$status" == "Complete" ]; then
    echo "<result>Onboarding Complete</result>"
elif [ "$status" != "Complete" ]; then
    echo "<result>Onboarding Not Complete</result>"
fi

In Jamf, that will look like this:

Display Name: Onboarding Status
Description: Checks to see if the onboarding defaults string is set to complete
Data Type: String
Inventory Display: Extension Attributes
Input Type: Script

Great, now we have another attribute to work with, we need to actually do something with it.

Smart Group

Let's create another Smart Group based on this new attribute.

Display Name: Devices - Lab - Onboarding Complete
Criteria: Onboarding Status IS Onboarding Complete

Done. Now we can scope any future policies to this group knowing that they have very likely finished doing what we need them to do first, and that they are in a certain state. You could also base other Smart Groups off of this, too. Perhaps you only want room specific software to install after this whole process is complete so that the users can just get on with the basics? Clone this, and add an AND  clause with the room information. You then have a group based on the room AND that they need to have completed the onboarding.

Right, let's tackle the final two policies.

Installing NoMAD & NoMAD Login

Our lab machines are authenticating against Active Directory. They are not bound, and haven't been for some time. Quite frankly, it's a nightmare. To get around that issue, I make use of NoMAD and NoMAD Login.

If you haven't heard of these, it's worth taking a look. However, keep in mind that Jamf acquired them back in 2018: https://www.jamf.com/resources/press-releases/jamf-acquires-nomad-the-leading-solution-for-streamlining-mac-authentication-and-account-management/ - Since then, nothing much has really happened development-wise, as they're pushing the Jamf Connect (paid licence) angle.

Not all hope is lost yet. Work is underway with NoMAD 2 with all sorts of quality of life improvements, and feature updates. It is not production ready.

Joel Rennich / nomad2

NoMAD the second major version.

GitLab

For now, we'll continue to use the versions available from nomad.menu.

The first thing we'll need to do is download and get the PKGs on to your distribution point(s). I'll leave that part up to you. But, if you want to know how I'm syncing HTTPS DP's, let me know. I'll write something up.

My only suggestion is to number these packages. You want to install them in a specific order.

• 1.NoMAD.pkg
• 2.NoMAD-LaunchAgent.pkg
• 3.NoMADLoginAD{version}.pkg

I have found that not installing in this order can lead to unexpected behaviour.

Policy

With the files in place, we now need to create the policy. The settings for mine are as follows:

Display Name: Lab - Zero Touch - Install - NoMAD
Category: Lab - Onboarding - General
Trigger: Custom: labzt-nomad
Execution Frequency: Once Per Computer

When you add the packages to the policy, they should install in order, like this:

We'll scope this to our Devices - Lab Auto Advance - Zero Touch Smart Group to ensure that it runs when called from the DEPN script.

Configuration Profile

The other really important part you're going to need to create for NoMAD is a Configuration Profile, and ensure that it is scoped to these devices. Again, the best option here is to our Devices - Lab Auto Advance - Zero Touch Smart Group.

Due to the obscene number of settings, and environment variations, I can't even begin to tell you what you should have set in here. What I would suggest is to make use of the Profile Creator tool.

GitHub - ProfileCreator/ProfileCreator: macOS app to create standard or customized configuration profiles.

macOS app to create standard or customized configuration profiles. - GitHub - ProfileCreator/ProfileCreator: macOS app to create standard or customized configuration profiles.

GitHubProfileCreator

Use this to create a payload for both NoMAD and NoMAD Login. This has been working for me in this way for 5 or so years, back when these devices were running through Open Directory. Way before our Jamf times, and before I was part of this team, but somehow still had some say in how the Mac's behaved … (I'm beginning to feel like I've been set up).

However, there is an alternative. I have not tested this method yet.

Jamf has greatly improved the ability to import custom schemas for external applications within their configuration profile creation tool. And there are schemas out there for both of these applications.

ProfileManifestsMirror/com.trusourcelabs.NoMAD.json at main · Jamf-Custom-Profile-Schemas/ProfileManifestsMirror

Jamf JSON schema manifests automatically generated from ProfileCreator manifests (https://github.com/ProfileCreator/ProfileManifests) - ProfileManifestsMirror/com.trusourcelabs.NoMAD.json at main ·...

GitHubJamf-Custom-Profile-Schemas

ljcacioppo-schemas/menu.nomad.login.ad.json at main · Jamf-Custom-Profile-Schemas/ljcacioppo-schemas

Custom schemas for Jamf Pro. Contribute to Jamf-Custom-Profile-Schemas/ljcacioppo-schemas development by creating an account on GitHub.

GitHubJamf-Custom-Profile-Schemas

I plan on migrating to this method, as it will make it far easier to update/change settings in the profile on the fly. Currently, it's stuck as a single uploaded .mobileconfig that I created years ago. If you'd like to see a post on this testing, let me know. But for now, here's a quick screenshot of not even a quarter of the settings made available through the custom schema.

OK, that's NoMAD dealt with. On to the final part of the puzzle.

Remove Auto Logon

With all our applications installed, all we have left to do is tell the device to remove the auto logon entry. Otherwise, it's just going to keep signing in as our default user. This may actually be useful to you, but not for me, and not what we're trying to achieve here.

As you can see from the DEPN script segment at the start of this post, we're calling the "labzt-remove-autologon" policy trigger. So yes, we're creating another policy!

Policy

Cast your mind back to part two of the series.

Fully Automated Lab iMac Deployment with Jamf Pro & ADE: Part 2 - PreStage to Auto Logon

In the second post of the series, we cover the creation of scripts, smart groups, policies, and extension attributes for the auto logon stage.

Tech Talk & Mind DumpsGray

We made use of the AutoLogin script from brunerd.

macAdminTools/setAutoLogin.jamf.sh at main · brunerd/macAdminTools

Tools for the MacAdmin. Contribute to brunerd/macAdminTools development by creating an account on GitHub.

GitHubbrunerd

If we take a look at lines 15-17 of that script, we can see that by passing a blank value, it will disable auto login for us.

#JAMF script parameters are shifted +3
#provide a username, if blank will disable autologin
USERNAME="${4}"

We've already got the script in place with the parameter options. This makes our policy pretty simple.

Display Name: 20. Lab - Zero Touch - Onboarding - Remote Auto Logon
Category: Lab - Onboarding - General
Trigger: Custom: labzt-remove-autologon
Execution Frequency: Once per Computer

Next, we'll configure the Scripts option to run our Lab - Zero Touch - Onboarding - Set-or-Remove Auto Logon with blank values for Username and Password.

And finally, we'll configure the Restart Options to Restart Immediately.

As for scoping, we'll scope this to Devices - Auto Logon Enabled Smart Group. This will ensure that it can only run on devices that have fallen in to this Smart Group.

And that's it, we're done.

Summary

Not much was really done in this post, but it was an important final step in getting the device in to a user ready state. With all of these steps together, we can now assign a device to our Lab - DEP MDM server in Apple School Manager, have it automatically assigned to the PreStage in Jamf. If we include some Inventory Preload information, we can tell it about asset tags, rooms, and all sorts (optional but heavily recommended).

Turn the device on, and watch it go!

We can now take a device from this:

Through this:

Where all the person on the other end sees is this:

Which, after an automatic restart, leads us to:

A fully automated Zero Touch Lab iMac Deployment with Apple School Manager and Jamf (and a boat load of policies, scripts, packages, and if you're in to it, prayer).

We are successfully deploying machines like this, across multiple sites. In a live environment, not just test.

Closing

I truly hope that you have found this series useful, and that it has given you some ideas for your own environment. I'd really love to hear from you about what you're doing, or how I can improve my process, too.

You can find me in a few places online.

1. Mastodon
2. MacAdmins Slack (#uk / #lab-environments / and more …)
3. Matrix @grayw:opensuse.org

Yep, I think that will do it.

And again, thank you so much for following along and reading. Don't forget to check back on Thursday (or use RSS ;)) for the full summary post.

The post Photo for this post series was by Quaritsch Photography on Unsplash

Welcome to the fourth post in this blog series. Much like the opening's for the previous posts, I'd suggest you read the others first if you haven't already, as we're building towards something. You can read them here:

Jamf Deployment Series - Tech Talk & Mind Dumps

Over the course of this blog post series, we will cover the whole process of automating the setup of iMac’s in a multi-user lab environment.

Tech Talk & Mind Dumps

For this post, we're going to finish building out the rest of the application policies we need for deployment. Then, create some more smart groups, and make use of a feature in Jamf Pro that very rarely gets mentioned, but quite possibly one of my favourite. Let's start with that!

Inventory Preload

This is a feature of Jamf Pro that I very rarely see get a mention, possibly because it's just not that fun. But, used right, in combination with Smart Groups and Extension Attributes, you can really cut down on your work here.

You can read more about it here:

Inventory Preload - Jamf Pro Documentation | Jamf

The Inventory Preload setting allows you to upload computer and mobile device inventory data before devices are enrolled. The preloaded data will be applied to computers and mobile devices when ...

Jamf

But, quite simply, it allows us to pre-populate Jamf with information about a device before it's enrolled (and after, too!).

When deploying lab style environments, you're very likely deploying to different rooms, buildings, or clusters that require different things. Building up different onboarding workflows for all of these would be a nightmare. We want to automate things as much as possible! So, that's what we're going to do. For my environment, I make heavy usage of the Room, and custom Usage Type attributes.

If we had a new order of 100 devices coming in, destined for 3 different rooms, would you want to manually assign that room information AFTER enrolment along with the usage type? Of course not. That would also completely break our fully automated workflow!

Instead, we'll make use of Inventory Preload by creating a CSV file with the following information:

We're now telling Jamf, as soon as you see that serial number, I want you to assign the Asset Tag, Room, and (Extension Attribute) Usage Type to that device. Once this is assigned, it will also automatically update our Smart Groups.

If you don't use asset tags, you can leave that out, but you can instantly see how powerful this simple tool can be. For a full list of default values, take a look at the documentation, but extension attributes are fully useable by prefixing the column with EA and then the name.

With this data available, we can now make use of some Smart Groups that are based on Rooms to deploy different applications, printers, or other settings as part of the whole onboarding process.

As I said, it's not very fun, but I love it. Especially as it gives us the ability to make bulk changes to existing devices, too. Want to move a batch of devices to another room? Easy, just create a CSV with their serial number and add the information you want to change. They'll see these changes on their next check-in.

Smart Groups

Let's build out some more Smart Groups based on the information provided in our Inventory Preload.

In our preload example, we told Jamf we're adding devices to Room 01 - 03. Let's create Smart Groups with the correct criteria.

• Display Name: Blog - Room 01
• Criteria: Room / Operator: is / Value: Room 01

We'd repeat that for the other rooms. Now, as soon as our first device completes enrolment, Jamf will update the computer record with "Room 01", and it will be added to our smart group, and so on.

When it comes to Extension Attributes and Smart Groups, let your imagination run wild! But don't go too crazy, otherwise you could end up with policy scope spaghetti.

Application Policies

Jamf is preloaded with our data, we've got Smart Groups for our rooms. All we need to do now is finish building out our policies for the applications / settings required for each of these locations and scope them to the relevant smart groups.

General Deployment

Our General Deployment will cover the basics that all our Lab machines are going to need. We'll scope these policies to Lab - Auto Advance. Scoping them this way ensures that any device coming through this PreStage will be eligible for them. I feel that this is safe to do, as they're all configured to run using a custom trigger. The only time they're going to run is if we tell them to.

System

• Install Rosetta 2 (Scoped to Smart Group if device has Apple Silicon)
• Set Device Time Zone and NTP Servers
• Set Device Name (BLOG-%SERIALNUMBER%)

Browsers

• Microsoft Edge
• Mozilla Firefox
• Google Chrome

Office Applications

• Microsoft Office 365 (Inc. Teams)
• Remove Outlook for Lab Machines
• Keka

Media Applications

• VLC
• Audacity
• Handbrake

Adobe

• Cache the installer for Adobe Creative Cloud 2022
• Install Adobe Creative Cloud 2022

There's a reason for the caching. I've found that if you cache the installation files, you get far fewer failures than you would if you leave it to it. It can also cut hours off the installation time.

Specific Room Requirements

With all the general requirements have met. You can start looking at any individual room needs. Ensuring that anything here is scoped to the relevant Room 0x Smart Group.

Room 01

• Room 01 Printer
• Scanner Drivers
• Extra Specialist Software

Room 02

• Room 02 Printer
• Extra Specialist Software

And so on. As the device moves through the script, it will query Jamf to ask if there's any other relevant policies that are outstanding. So these will need to be configured to run on recurring check-in. Just make sure you're only running them once per computer (or whatever that policy requires).

Combining with Previous Stages

We've built up quite a number of moving parts if you look back through the posts, and it's easy to get lost in this forest. So let's take a step back and look at this in order.

• Ordered devices, which are automatically added to Apple School Manager by supplier
• Assigned the devices to our MDM "server" of Lab-DEP
• ASM syncs with Jamf and assigns them to the matching Lab - DEP setting under Automated Device Enrolment
• The Lab - Auto Advance PreStage automatically scopes and assigns them to itself based on the settings we configured

• We preload Jamf with Inventory Preload to give it more information on each of the devices
• Smart Groups are in place to automatically update based on the device information provided in the preload
• There are policies scoped to a Smart Group based on the PreStage that will tell the device to automatically log in with our local admin account created during PreStage
• We then scope further policies to another Smart Group based on whether a device has automatic login enabled
• Power on the device, and it makes its way through setup using Auto Advance
• Once one of these devices logs in, the policy will trigger and install DEPNotify, and then kick off the script we configured to install our policies using a full screen style feedback

• By adding some Jamf Recon calls within this script at certain points, we ensure that devices are keeping Jamf up to date with information as it goes
• Once the general policies complete, we have further policies scoped to specific rooms that we can call on towards the end of the script with a Jamf Policy check

Here's a GitHub Gist of what this script could look like following our path and examples:

As you can see, we're working through our application policies, installing all the general software. Once they are done, we make a final recon call back to Jamf to update the inventory, and ensure any smart groups are up-to-date. Once that's done, we run a policy check to see if there are any other policies remaining. In our case, this is where the different room policies would run based on the smart groups. So, any in the "Blog - Room 01" group would run the policies scoped to those, etc.

On line 62, you'll notice that I'm writing out an "onboardingComplete" string to a custom plist file. And then, lines 67 - 70 we install NoMAD and remove the auto login we've configured.

We'll cover these last bits in the next post, where we concentrate on getting the device "User Ready".

Summary

This post covers preloading information in to Jamf, allowing us to sort our machines in rooms, buildings, custom groups, and many other ways.

Creating Smart Groups to make use of this information before Jamf even sees the device.

Categorising our application policies, and adding them to the script.

And finally, putting all those steps together makes you realise how much work goes in to something like this.

From an external appearance, it seems as though things are swimming along easily. Underneath, there are things swishing left, right, up, down, and possibly in some directions that may not even be considered directions. But, that's why we have jobs. Make the seemingly impossible requests look easy.

We're almost done with this series of posts, and I hope you've enjoyed them and that they've been useful. The next post will cover the last few pieces of the puzzle in getting the device in to a true user ready state.

And then, the finale. The summary post, where we'll step back and marvel at the monstrosity that has been born. I'll also be creating a high-level flow chart style overview on how this whole thing fits together.

The post Photo for this post series was by Quaritsch Photography on Unsplash

Hello, and welcome to post three in this blog post series of deploying iMac's in a Lab environment. If you haven't already, I'd urge you to seriously consider going back over the first two posts, which lays the groundwork for getting here. Without it, things may not go to plan. Go on, off you trot.

Jamf Deployment Series - Tech Talk & Mind Dumps

Over the course of this blog post series, we will cover the whole process of automating the setup of iMac’s in a multi-user lab environment.

Tech Talk & Mind Dumps

Back?

Today, We're going to concentrate on preparing our environment for deploying the applications we need. There are a few ways we could do this. But, as this is all about full automation, we're going big, and with style!

DEPNotify has been part of my Staff on-boarding workflow for quite a while. It's a pretty "simple" method, and mostly used as feedback for the user to see what's happening. Although, you can do some incredibly cool stuff with it. So, where the hell do I start?

DEPNotify Package

Let's begin by getting the DEPNotify application, and making the package available on our Distribution Points. Grab the latest version from the GitLab repo and add it to your relevant DP's:

Releases · Joel Rennich / DEPNotify

GitLab.com

GitLab

DEPNotify Script

Next, we're going to add the script required to bring all of this together in the background. Or, as Chad from Rocketman Tech infers - making the magic happen.

CREATING MAGIC WITH ENDPOINT PROVISIONING PART 1 – THE “TA DA!” OF DEPNOTIFY

“Sometimes magic is just someone spending more time on something than anyone else might reasonably expect.”‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎~Teller Magicians spend a lot of time perfecting skills that if, done right, can’t be seen by their audiences. I…

RocketmanChad Lawson

Previously, I've always used the DEPNotify-Starter resources from Jamf's GitHub repo. But this time, I'm going to make use of the script by Rocketman:

GitHub - Rocketman-Tech/Onboarding-With-DEPNotify: Create an end user-based provisioning workflow for Jamf deployments with a DEPNotify interface.

Create an end user-based provisioning workflow for Jamf deployments with a DEPNotify interface. - GitHub - Rocketman-Tech/Onboarding-With-DEPNotify: Create an end user-based provisioning workflow f...

GitHubRocketman-Tech

Just like before, we'll add the script to Jamf, and configure the options to make it easier in the future. In 6 months, are you going to remember what's supposed to go in "Parameter 5"? If so, kudos, I'm lucky if I can remember week to week.

In its current state, the script isn't really very helpful for us. We need to tell it what we want it to do. In this case, we want to install specific pieces of software. To do that, we're going to need policies for it to call on. I've got one or two that are needed …

But, let's go through a few. In keeping with the example workflow within the DEPNotify script, we'll start with some Machine Configuration.

To keep the test times short, I'm going to use two of my smaller scripts. The first is to set the device name to our standards, and the second to configure the time zone and NTP settings on the device. In the DEPNotify script, that would look like this:

## EXAMPLE WORKFLOW
##
# ## Machine Configuration
DEPNotify "Command: MainText: Configuring System Settings"
DEPNotify "Status: Setting Computer Name"
jamfCommand labzt-onboarding-setdevicename
DEPNotify "Status: Setting Computer Time Zone to UK"
jamfCommand labzt-onboarding-settimezonentp

But what about something a bit more substantial. Well, as we begin to build out what we need to deploy, we keep adding to the script:

## EXAMPLE WORKFLOW
##
# ## Machine Configuration
DEPNotify "Command: MainText: Configuring System Settings"
DEPNotify "Status: Setting Computer Name"
jamfCommand labzt-onboarding-setdevicename
DEPNotify "Status: Setting Computer Time Zone to UK"
jamfCommand labzt-onboarding-settimezonentp
#
# ## Browsers
DEPNotify "Status: Installing Microsoft Edge"
DEPNotify "Command: MainText: Starting software deployment.\n\nThis process can take up to 3-4 hours to complete."
jamfCommand labzt-onboarding-edge
sleep 3
#
# ## Office Applications
DEPNotify "Status: Installing Microsoft Office 365"
jamfCommand labzt-onboarding-office365
sleep 3
#

We just keep building it up until we've got everything we require. While we're testing, let's keep it to these few simple jobs. We don't want to be waiting for hours on each test.

Now we have the script performing a few actions, we need to actually make use of it. Policy time!

Onboarding Policy

Let's create the policy to actually make use of this script. Again, this section is going to be image heavy, as it's much easier to convey all the things we're doing.

First, we'll configure the General tab. We're starting the policy name with number "10". Policies run in an alphanumerical order.

Policy Naming Tangent

You can read a discussion on this on the Jamf Nation Community forum:

Policy Execution Order

Hello everyone, hope you all are well. I would like to get policies to execute in order. I would like one policy to run last no matter what. I have been working on this huge project with DEP Notify. I made a post about it a little while ago. Do you guys know how to get policies to run in a specific …

Jamf Nationkadams Contributor

It's also covered here:

CREATING MAGIC WITH ENDPOINT PROVISIONING PART 3 – THE POLICIES

“Any sufficiently advanced technology is indistinguishable from magic.”‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ …

RocketmanChad Lawson

Back to the Policy

Anyway, back to it.

We want this policy to run at login (see where we're going with this and the auto login?). We're also going to have this run at a recurring check-in, just in case it fails to run immediately. There's also a custom event trigger. You never know. One of the joys of deploying Apple devices is the unpredictability!

We only want this to run once per computer, especially with recurring check-in selected. Don't want to be attempting to install all the software every check-in!

So, what is it that we want this policy to actually do? First, we'll need to have it install the DEPNotify package for us.

Then, we want it to run the script to actually do something with DEPNotify. We need to set the priority to After. This will make sure the script only runs once the package installs. If we try to run it Before, it's not going to do anything as DEPNotify won't be there.

We're also going to pass the -fullScreen option, as we don't want users walking up to the devices and using them while we're trying to deploy software. We'll also set the title.

Finally, we want to scope this to the Smart Group we created in the previous post (Devices - Auto Logon Enabled) that contains devices that have auto logon enabled. This ensures that we're only targeting devices that are automatically logging on. We do not want this deploying to loads of machines when a user logs in by mistake.

Summary

While I could probably add more to this post, I think this would be a suitable break point. The next part would make this feel too long.

What did we do in this post?

• We've downloaded DEPNotify and added it to our Distribution Points
• Added the script that will deploy our software
• Made changes to the script to actually do something
• Created a new policy that will install DEPNotify, and run the DEPNotify script to install the software. This will happen at logon, or, at the next convenient check-in, if it's unable to run immediately.

If you were to run a machine through this process right now as it is, it would still give great results. You could assign it to your Lab - DEP MDM server in ASM, plug it in, and have it at the desktop with Office and Edge installed without having to put your hands on it.

In Part 4, we're going to go through the rest of our policies, and really build it out to do everything we need it to do. Along with some additional tips on really making the most of Smart Groups and another feature within Jamf Pro ;)!

Part 5, we'll complete the last few additions to finish it all off, making the device user ready.

And finally, Part 6, we'll go through a bit of a summary of everything we've done and look at how the whole process hangs together from a high level overview. If I receive any feedback, I'll also probably go through that here.

The post Photo for this post series was by Quaritsch Photography on Unsplash

Hello and welcome to the second post in this series. If you haven't already read the first, I'd suggested you go back and read it. It's quite important, as it covers some prerequisites for getting this workflow up and running. Skipping parts may result in something not working. Go on, we'll wait for you:

Fully Automated Lab iMac Deployment with Jamf Pro & ADE: Part 1 - ASM to PreStage

In this first post of the series, we cover Apple School Manager, Jamf ADE, and the initial PreStage settings.

Tech Talk & Mind DumpsGray

In this post, I was going to cover the creation of all the scripts and smart groups. However, by the time I'd finished just one part, it felt like enough. So, this post will cover the creation of the scripts, smart groups, and extension attributes required to take us to the auto logon stage of our setup.

Enjoy!

Auto Advance PreStage Smart Group

If you're new to Jamf, you may not fully appreciate the usefulness of Smart Groups … yet! They can make life so much easier. For us, they're going to be incredibly helpful in ensuring we scope policies to exactly where we want them to go, and at the right time. If you haven't already, I'd suggest you read up on Smart Groups:

Smart Groups - Jamf Pro Documentation | Jamf

Jamf Pro allows you to create smart groups for managed computers, mobile devices, or users. You can create smart groups based on one or more inventory attributes. To avoid issues, smart group criteria ...

Jamf

Anyway, the first Smart Group we're going to make use of is one that contains devices that are enrolled via the Lab - Auto Advance PreStage method.

An image speaks a thousand words, so we're going to be making heavy use of them in this post!

Any devices that come through that PreStage will now be automatically added to this Smart Group. OK, great. Now, we're going to want to do something with this group, otherwise what's the point.

Auto Logon Script

One of the major issues I've been facing up to this stage has been giving the local technician decent feedback about how the software installation has been going. So far, I've just been running policies in the background while the device has been seemingly idle at the log on window. This is not overly helpful for them unless they're checking the policy history. I wanted more, and it's taken a few months to get to this stage. But the answer was "simple".

We're going to have the device automatically sign in as our local admin user that was created as part of our PreStage settings. Unfortunately, this doesn't seem to be an option in Jamf Pro right now, which I think is incredibly short-sighted. You're allowed to skip account creation, but then not sign in … Might be worthy of a feature request.

To achieve our goal, we're going to make use of this:

macAdminTools/setAutoLogin.jamf.sh at main · brunerd/macAdminTools

Tools for the MacAdmin. Contribute to brunerd/macAdminTools development by creating an account on GitHub.

GitHubbrunerd

Which I discovered over on brunderd's blog here:

From here, we're going to need to add this script to our Jamf Pro instance, and configure the options (makes it easier in future if you name these now). After that, we're going to create a policy to actually do something with the script, and scope it to our Devices - Lab - Auto Advance smart group that we created earlier.

So here, we've added the script to Jamf, and then updated the parameter labels to Username and Password. This will make it much easier to remember what does what when it comes to creating the policy.

Auto Logon Policy

Next, we'll create a new computer policy. I've prefixed this with a "00." in an attempt to help ensure that it is the very first thing that runs when it tells Jamf that the enrolment is complete.

Above, you can see where those parameter labels come in to play.

Below, we've configured the device to automatically restart as soon as the script completes. This is important, as we've just configured the device to automatically login as this user on startup, not when the script runs.

With those two parts done, we now have a policy that will run at enrolment complete for any device that comes through that PreStage. It will run the script to enable the auto logon at startup. Now we need to make use of this new-found freedom.

Auto Logon Extension Attribute

Next, we're going to want to know when a device has auto logon enabled. Without knowing this, we can't really act on it reliably. I think the easiest option here is to make use of Extension Attributes:

Computer Extension Attributes - Jamf Pro Documentation | Jamf

Extension attributes allow you to collect extra inventory information. Extension attribute values are populated using an input type, which can be any of the following: Text field Pop-up menu Script ...

Jamf

We're going to create an extension attribute that runs a script on the device to see if auto logon in enabled, then return a status to Jamf. Once that information is back, we can act on it.

We can achieve this by making use of the incredibly helpful answer from thoule in the Jamf Community:

Re: Smart Group based on policy

Your smart group needs to identify the difference between a computer that has run your script and one that hasent. If nothing jumps out at you, then I tend to create a plist as part of my script defaults write /Library/Preferences/com.toddco.plist scriptWasRun -bool YES Then an extension attribute t…

Jamf NationSobchak Contributor

With a few tweaks, we can check for our entry on the login window to see if the result matches our local admin username, then return a result based on that. We knew it was writing out to this file on line 108 of brunerd's login script.

macAdminTools/setAutoLogin.jamf.sh at 9146c633b16534b2436727faea6de8df9395f7a4 · brunerd/macAdminTools

Tools for the MacAdmin. Contribute to brunerd/macAdminTools development by creating an account on GitHub.

GitHubbrunerd

If we check the Extension Attributes page of the device that we have deployed with this policy scoped to it, this looks to be true:

On reflection, I probably could have shortened this to simply return "Enabled" or "Disabled".

Auto Logon Status Smart Group

Phew, we've come a long way already, but there's still so much left to do. Now that we've got devices telling us if they have Auto Logon Enabled or not, we need to do something with that information.

I want to scope our next set of policies to run on devices that are sat there waiting on the desktop for us. It's important that this happens at the desktop due to the way DEPNotify displays things. This will be more obvious later. For now, let's create a Smart Group based on this extension attribute.

Here's the Smart Group with the criteria, checking that the Auto Logon Status is Auto Logon Enabled. Any machine that is returning that information to Jamf will now automatically be made a member of this Smart Group. If we check that, we can indeed see that the device that is waiting at the desktop is indeed a member:

Summary

We've actually covered quite a lot of ground in this post, and I think that adding any more to it would actually be detrimental. Especially with my scattered way of thinking.

For this post, we've created a PreStage Smart Group to make use of the PreStage setup from the previous post. Created a script and a policy to automatically log on our local administrator created during PreStage Enrolment. And, created an extension attribute that runs a small shell script to query a machine to see if auto login is enabled, adding it to a new Smart Group if that is true.

Phew! If we add the previous achievements to this one, we've actually done quite a lot:

• Configured Apple School Manager for devices to be automatically added by suppliers
• Added MDM servers to Apple School Manager
• Added Automated Device Enrolment settings to Jamf to line up with ASM
• Created a PreStage Enrolment task that will automatically assign devices to it that are assigned to our Lab - DEP from ASM. When turned on, these devices will then make use of the Auto Advance feature in macOS Big Sur or later to automatically run through the setup screens. Jamf will create a local administrator account for us, and skip the rest of the account creation process.
• Created a script that will automatically log our new local administrator account in.
• Created a policy for that script that will run once enrolment is completed, and scoped that only to machines that come through our Lab - Auto Advance PreStage.
• Created an Extension Attribute that will query the machine to see if our auto login is enabled and active.
• Created a Smart Group that will automatically add devices to itself if that extension attribute comes back as our true statement.

At this stage, we can now have a device taken out of the box, plugged in and automatically sat waiting at the desktop within about 5 minutes. All we need to do now is push software at it. Easy … right? Oh Apple, you little tinker.

Again, if you have any feedback or suggestions on improving this process, I'd love to hear from you. You can usually find me lurking in the MacAdmins Slack in various channels: macadmins.slack.com

This blog post series image Photo is by Quaritsch Photography on Unsplash

Welcome to part one of my blog post series about deploying lab (multi-user) iMac’s in a fully automated way, from box to … bench? I’m not sure how many posts this is going to be split down to yet.

I can’t guarantee that this is the perfect way of doing it, but it’s what I’m doing right now. Not only that, but I’d love to hear your feedback in areas where this could be improved. There are a lot of moving parts, so if you’re following along, I’d advise you wait for all parts to be published, go through it, and plan it out for your environment rather than just blindly following.

In this first post, I’m going to detail some prerequisites and the setup required to make any of this possible.

I’m mostly writing this for myself, because, if I ever have to try to put any of this back together again, I’m going to need notes. This has been the culmination of a lot of learning, and many, many mistakes over the past few years that I’ve been working in this team.

Pre-Requisites

Apple

The very first thing you’re going to need in place is either Apple Business Manager, or Apple School Manager. This whole process relies upon Automated Device Enrolment (previously known as Device Enrolment Program (DEP)). Without it, this entire automated process falls at the starting gate.

Your devices will need to be running macOS Bug Sur or later.

MDM (Jamf Pro)

The next thing you’re going to need (at least if you’re following along with me), is Jamf Pro. I’ll be working from a self-hosted installation, but I see no reason as to why this wouldn’t work with the Jamf Pro Cloud offering. If I get around to it, I may actually try it from the Beta Cloud service, too.

Within Jamf Pro, you’re going to need to have at least one HTTPS distribution point configured to ensure the machines can download the required packages when prompted.

You can read through the Jamf documentation on setting these up here, so I won't cover these in-depth configs:

File Share Distribution Points - Jamf Pro Documentation | Jamf

A server with an AFP or SMB share can be used as a file share distribution point. Before you can use a file share distribution point with Jamf Pro , you must set up the distribution point and add it ...

Jamf

Network Infrastructure

And, of course, none of this will work without a properly configured network with DHCP, and a clear shot out to all the required Apple and Jamf endpoints.

Due to the myriad of network equipment and personal configurations out there, I’m not going to cover this section at all within any of these posts.

You can find all the network requirements for Apple services within their documentation here:

Use Apple products on enterprise networks

Find out which hosts and ports are required to use your Apple products on enterprise networks.

Apple Support

And, similarly, you can find all the network requirements for Jamf Pro here:

Network Ports Used by Jamf Pro - Jamf Pro Security Overview | Jamf

The complete list of required ports depends on the specific services and features that are enabled in a particular environment. The following ports are required to support basic functionality in all ...

Jamf

I appreciate that not all Apple Admins have networking experience, so if this is the case, I suggest you discuss this with your relevant networking team to ensure that this will be possible for you.

Right, that’s it. On with the rest of the show.

Apple Business/School Manager Setup

As I’ve already mentioned, one major part of this will be the configuration of your A(B/S)M account.

Step 1: Ensure that your suppliers are correctly setup to add devices to your account.

When you order a device from your supplier, you’re going to want to make sure that they add it to your ASM account. I’m going to refer to it as ASM from here, as that’s what I’m using - but I believe they are interchangeable.

To do this, you’re going to need their Apple account details and add them to your approved suppliers.

Once this is done, whenever you order your devices, they will be automatically assigned to your ASM account. Like so:

Without this, your devices will not be available for ADE (DEP) style enrolment in to Jamf Pro, which will make it impossible for later steps.

Step 2: Set up your MDM servers

Next, you’re going to want to make sure that add your Jamf Pro service as an MDM server.

During our original setup and mandatory kick-start induction, this was originally set up as just one MDM server, with all devices being automatically assigned to it. It wasn’t until I spotted something in an Apple Event screenshot almost a year and a half later that I even considered this next part to be a thing. Once I tried it, it really opened my eyes and completely changed the way I was doing things within Jamf.

Despite it being one single Jamf Pro instance, you can see here that I’ve configured multiple MDM servers.

Above, you can also see that I have configured a “Jamf - Lab DEP” server. Again, this is still pointing to the single Jamf Pro instance.

All will become clear when you see the Jamf side of this. But simply, any device that’s an iPad will be automatically assigned to the iPad server, and an iPhone to the iPhone server. Quite self-explanatory.

Jamf Pro Setup

I will not be teaching you how to configure this in this blog post series, as Jamf already has this documented:

Automated Device Enrollment Integration - Jamf Pro Documentation | Jamf

Enrollment is the process of adding computers and mobile devices to Jamf Pro . This establishes a connection between the computers and mobile devices and the Jamf Pro server. The Automated Device ...

Jamf

I am not taking responsibility for you messing up your server configurations and breaking everything ;).

Anyway, once this is configured, you will have your respective Automated Device Enrolment settings on the Jamf Pro side, too:

As you can see, mine (almost) mirror that of the ASM side, making it obvious what they’re for. I have no idea of the skill level of the person that may need to manage this after me, so the kindest thing to do is to try to make it obvious what I’m trying to achieve.

Step 3: Set up your PreStage Environment

With the server connections in place between ASM and Jamf, we can now start to configure our PreStage environment for the Lab devices. For a deeper dive on this topic, I’d suggest reading the Jamf documentation.

Computer PreStage Enrollments - Jamf Pro Documentation | Jamf

A PreStage enrollment allows you to create enrollment configurations and sync them to Apple. This enables you to enroll new computers with Jamf Pro , reducing the amount of time and interaction it ...

Jamf

The important part of this feature that we’re going to be making use of, though, is Auto Advance. This is key to the full automation side. It’s also why your devices need to be on Big Sur or later, and you need to have working DHCP.

We’ll now configure our PreStage to do what we need it to do. Another key part here is to ensure that you’re automatically assigning devices from the Lab DEP server to this PreStage.

By doing this, anything that you assign to the Lab DEP server within ASM is going to be automatically synced with Jamf Pro’s Automated Device Enrolment configuration. In turn, automatically assigned to this PreStage, ensuring that you don’t have to do any manual assignments. Just assign them once at the high level, and you’re done. It’s worth noting here that if you change the assigned MDM server in ASM, that’s going to change in Jamf, too. So, if your device is no longer going to be used in a Lab, move it!

We're going to have the PreStage automatically create a local administrator, and then skip the account creation process.

Here are a couple of screenshots of all the settings I’ve configured for this PreStage. As you can see, I’ve also added a few extra bits that will make my life a little easier. You may, or may not, need to do this depending on your environment.

Note that I've selected the Lab - DEP ADE instance, and chose to automatically assign new devices.

With all these steps completed, we’re now in a great position to move on to the next part.

Summary

I think that’s enough for the first post in this series. The second post will head in to configuring the scripts, packages, and policies required to make the next stage possible.

But to sum up. In this post, we’ve covered the basic requirements needed for this to be possible like Apple School Manger ordering, along with how I’ve configured DEP on both the ASM and Jamf sides. And also the PreStage setup required to make the next steps possible.

As I said at the beginning, this is mostly for me for if I ever need to try to re-create this again (I hope not). But, if it helps someone else out there too, then that’s a bonus.

The post Photo for this post series was by Quaritsch Photography on Unsplash

When trying to download the installer for FortiClient, you'll find that they only provide an oh-so-helpful "Online Installer". In which, we find their "FortiClientUpdate.app". Which is also about as much use as a chocolate heat-sink as it never seems able to install updates anyway.

Deploying this will get us absoloutely nowhere. We need the offline installer which can be obtained by running this from terminal to show us where it downloads the temporary file to.

To do this, you're going to need to make sure that FortiClient isn't already installed on the device, otherwise I've found that it fails to download the "update". If you have, make sure you run the FortiClient Uninstaller.app from your Applications folder first.

• Drag the .app file somewhere, desktop, downloads, whatever tickles.
• Ctrl + Click > Show Package Contents
• Under Contents, Ctrl + Click macOS, and open a Terminal Window/Tab at that location

• Run the FortiClientUpdate until it prompts you to "Install". Then stop here:

gray@fenrir MacOS % sudo ./FortiClientUpdate 

At the bottom of the terminal, you should see the location where it has downloaded the offline installer

[update:INFO] fcn_upgrade:562 Download FortiClient Connect successfully. Copy it to /var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/fctupdate/FortiClient.dmg

Copy this file to wherever makes life easier for you. I usually go for downloads.

sudo cp /var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/fctupdate/FortiClient.dmg ~/Downloads/

When you open this DMG, you'll have access to the .mpkg

I've noticed a number of issues when attempting to download .mpkg files from Jamf ditribution points on Monterey. I have no idea why, the error is simply that the file does not exist. Big Sur devices still seem to be able to download it just fine (same policy, same file, same DP).

I took the simple option here and renamed the file to FortiClient_{version}.pkg. It doesn't seem to have had any odd effects. As far as I can tell, there's no reason for it to be an .mpkg, as there aren't other .pkg's within it that it's trying to install.

This wasn't the first time I'd had to look up how to get this offline installer, but my original source no longer seemed to be available. I did find my saviour in AlmightyBob this time around:

Re: FortiClient VPN on MacOS Monterey - error code: -121

ok, so i got it to work but had to jump through some serious rings of fire to get it installed (since we switched to forticlient i’ve had to do this before. I’ve never been a fan of forticlient for this reason, its just easier when our hardware can update to the latest client and we can just downlo…

Fortinetdavidsteelerose New Contributor

As Fortinet are obviously deleting these posts when they get around to it, I thought I'd better write it down myself this time.

Post Photo by Lukas Hellebrand on Unsplash

Hello, and welcome to day 5. If you're jumping in here, head on over to: https://blog.grayw.co.uk/tag/100daysofswiftui/

Follow along from the beginning (or jump in wherever you like, whatever nibbles your biscuit).

Workspace

Today we'll be heading back over to the MacBook and Xcode, even though I certainly prefer the feel of Swift Playgrounds 4 so far.

Day 5 - Overview

Today we're going to be looking at if/else/else if, and a few other bits and pieces.

Check if a condition is true or false

//
// How to check a true/false condition
//

var someCondition = true

if someCondition {
    print("Do Something")
}

let score = 85

if score > 80 { // > is a comparison operator is score greater than 80
    print("You pass!")
}

let speed = 88
let percentage = 85
let age = 18

if speed >= 88 {
    print("Where we're going, we don't need roads.")
}

if percentage < 85 {
    print("Sorry, you failed the test")
}

if age >= 18 {
    print("You're eligible to vote")
}

// The comparison operators also work well with strings

let ourName = "Dave Lister"
let friendName = "Arnold Rimmer"

if ourName < friendName {
    print("It's \(ourName) vs \(friendName)")
}

if ourName > friendName {
    print("It's \(friendName) vs \(ourName)")
}


//

var numbers = [1, 2, 3]
numbers.append(4)

if numbers.count > 3 {
    numbers.remove(at: 0)
}

print(numbers)

// We can also check equality

let country = "Canada"

if country == "Australia" {
    print("G'day!")
}

let name = "Swifty"

if name != "Anonymous" {
    print("Welcome, \(name)")
}


var username = "swifty22"

if username == "" {
    username = "Anonymous"
}

print("Welcome, \(username)")

// Not an efficient way of doing it. If the value has hundreds of characters, it will count them all.
if username.count == 0 {
    username = "Anonymous"
}

// A more efficient, and easier way is to use isEmpty

if username.isEmpty {
    username = "Anonymous"
}

// Comparisons can also be done on enums (done on order in case list)
enum Sizes: Comparable {
    case small
    case medium
    case large
}

let first = Sizes.small
let second = Sizes.large

print(first < second)

How to check multiple conditions

//
// How to check multiple conditions
//
if someCondition {
    print("This will run if the condition is true")
} else {
    print("This will run if the condition is false")
}

// We can use else if's - but this can make code more complex
let a: Bool = true
let b: Bool = false

if a {
    print("Code to run if a is true")
} else if b {
    print("Code to run if a is false but b is true")
} else {
    print("Code to run if both a and b are false")
}

// We can use && (and)
let temp = 25

if temp > 20 && temp < 30 {
    print("It's a nice day.")
}

let userAge = 14
let hasParentalConsent = true

// We can use || (or)
if userAge >= 18 || hasParentalConsent {
    print("You can buy the game")
}

enum transportOptions {
    case airplane, helicopter, bike, car, escooter
}

let transport = transportOptions.bike

if transport == .airplane || transport == .helicopter {
    print("Let's fly!")
} else if transport == .bike {
    print("I hope there's a bike path")
} else if transport == .car {
    print("Time to get stuck in traffic")
} else {
    print("I'm going to hire a scooter now")
}

// If mixing && and || - it's good practice to use parentheses to make the result clearer
if (isOwner == true && isEditingEnabled) || isAdmin == true {
    print("You can delete this post")
}

• Conditions Review Test: 12/12
• Combining Conditions Review Test: 12/12

How to use switch statements to check multiple conditions

When should I use switch or if?

• switch statements must be exhaustive, so we must use a case block for every possible value to check, or have a default case (if using an enum, you don’t need default). So you may miss a case while using if/else

• When using switch to check a value for multiple possible results, that value will only be read once. If will read it multiple times.

enum Weather {
    case sun, rain, wind, snow, unknown
}

let forcast = Weather.sun

// Using Switch to check conditions
// By using a switch - Swift knows that we need to check all possible cases (exhaustive), and there can't be duplicates
switch forcast {
case .sun:
    print("It should be a nice day")
case .rain:
    print("Pack an umbrella")
case .wind:
    print("Wear something warm")
case .snow:
    print("School is cancelled")
case .unknown:
    print("Our forcast generator is broken")
}

// We can use a default case to avoid trying to achieve the impossible of coming up with every single possible match

let place = "Metropolis"

switch place {
case "Gotham":
    print("You're Batman!")
case "Mega-City One":
    print("You're Judge Dredd")
default:
    print("Who are you?")
}

// Fallthrough can be used to allow multiple cases to be run but is rarely used in Swift

let day = 5
print("My true love game to me ...")

switch day {
case 5:
    print("5 golden rings")
    fallthrough
case 4:
    print("4 calling birds")
    fallthrough
case 3:
    print("3 french hens")
    fallthrough
case 2:
    print("2 turtle doves")
    fallthrough
default:
    print("A partridge in a pear tree")
}

Switch Statements Review Test: 6/6

How to use the ternary conditional operator for quick tests

The ternary operator lets us choose from one of two results based on a condition in a concise way.

It has become important in SwiftUI, so is a key thing to know about.

// 2 + 5 - The + is a binary operator (they operate on two pieces of input)
// The is a ternary operator (it operates on three pieces of input). Let's us check a condition and then send back one value, or another value depending on the condition

let age = 18
let canVote = age >= 18 ? "Yes" : "No"
print(canVote)

// age >= 18 - The condition to be checked
// If true - Send back yes
// If false - Send back no

// Similar condensed form of if/else
// W T F - What? / True / False @scottmichaud

let hour = 23
print(hour < 12 ? "It's before noon" : "It's after noon")

// Check an array
let names = ["Jayne", "Kayleigh", "Mal"]
let crewCount = names.isEmpty ? "No one" : "\(names.count) people"
print(crewCount)

// With an enum

enum Theme {
    case light, dark
}

// Condition can also be put in parentheses
let theme = Theme.dark
let background = (theme == .dark) ? "black" : "white"
print(background)

Ternary Operator Review Test: 12/12

Summary

Today seemed to go on forever, and I was only making notes in the editor as I went, plus a few scrap notes here and there.

I'm not sure how long I'll keep blogging about each day, as I really don't have the time to learn, and to blog. I think I'm painting myself in to a corner again. It's leaving me with no time to do anything else I'd like to do with the few hours I get in the evening.

As you can tell, today was practically a copy/paste dump from the code editor, which seems kind of pointless and boring for a reader.

I'll see how the next few days go, and make a decision.

What are your thoughts?

Hello! And here we are at day 4 of the hackingwithswift.com 100 Days of SwiftUI course. As always, if you need to catch up with the rest of the posts, you can do so over here: https://blog.grayw.co.uk/tag/100daysofswiftui/ - If you're enjoying this series of posts, don't forget to follow the RSS feed.

Workspace

The workspace for today will be the iPad with Swift Playgrounds 4. I'm practically fully charged, so we'll see how this goes.

How to use type annotations

For day 4, we're going to be looking at the last part of complex data types. This will be type annotations.

When should type annotations be used:

1. When Swift can't figure out what type should be used
2. You want Swift to use a different type from the default
3. You don't want to assign a value yet

Why use type inference:

1. Can make code shorter and easier to read
2. Change the type quickly, and easily by changing the initial value

Type Inference - infers that type is string/int/double/bool because that's what the initial value is

• Type Annotations Review Test: 6/6

Summary: Complex Data

• Arrays store many values, and read them using indicies (zero-based)
• Dictionaries store many values, and read them using keys we specify
• Sets store many values, but we don't choose their order
• Enums create our own types to specify a range of values
• Swift uses type inference by default to figure out what data we're storing
• Type annotation allows us to force a particular data type

// Swift must always know what data type your constants and variables contain (type safe language)

// Variables & Constants
let surname: String = "Lasso"
let score: Double = 0 // If this used type inference, it would have been an Int
var isAuthenticated: Bool = false

let userName: String
userName = "@gray"

// Arrays
var albums: [String] = ["Red", "Fearless"]
var teams: [String] = [String]()
var cities: [String] = []
var clues = [String]()

// Dictionaries
var fosstodonUser: [String: String] = ["id": "@gray"]
var hrData: [Int: String] = [123456: "employeeName"]

// Sets
var fruits: Set<String> = Set([
    "Banana",
    "Apple",
    "Peach",
    "Orange"
])

// enums 
enum UiStyle {
    case light, dark, system
}

var style = UiStyle.dark
style = .system

Checkpoint 2

For the second checkpoint, the task was to create an array, and then print the number of items in that array. You also then need to print the number of unique items for that array.

My solution:

let displayNames = ["Batman", "TheRealJoker", "TheRealJoker", "Joker", "Penguin" ]
let numberOfUsers = displayNames.count
print(numberOfUsers)

let uniqueUsers = Set(displayNames)
print(uniqueUsers)

The first part to create the array and the count was fine. However, the unique part I couldn't think how to do straight away. So, I did a little search and got this:

Of course, Sets can't contain duplicate values. I didn't need to create it as a new array, so I left that part off.

Summary

Well, that's the end of day 4. I feel like I should have been able to get the unique items count thing without having to search, but there you go.

I seem to struggle with this single topic being split across multiple days. By the time I've got here, I'm forgetting what was said on day 1.

Hello, and welcome to day 3 of the 100 Days of SwiftUI blog series where I'm following the hackingwithswift.com course by the same name. If you've skipped the first couple of posts, you can go back over all the posts here: https://blog.grayw.co.uk/tag/100daysofswiftui/

Workspace

My workspace for today will be Xcode on the MacBook again. However, I think it's important to note that while I have opted to use the MacBook once again, I feel that I enjoyed my time in the Playgrounds editor far more.

It was an incredibly clean, simple interface, and just felt like a far smoother experience than Xcode. I’m certain this opinion will change once I get past the very basics, though.

How to store ordered data in arrays

The first part of today will be taking a look at how to store data in arrays.

Starting with the basics, we create and array much like any other variable or constant. Except this time, we wrap them in [] after the assignment operator =.

var goodGuys = ["Two Face", "The Penguin", "Joker"]
var badGuys = ["Batman", "Robin"]

let someLostNumbers = [4, 8, 15, 16, 23, 42]

When referencing a value in an array, we query its index. That is its location within the array. However, we start our count at 0, rather than 1.

print(goodGuys[2])
print(someLostNumbers[4])

We can add data to a variable array by using .append()

badGuys.Append("Joker?")

We need to keep in mind that we can't add any data we want to an array. If it contains strings, we can't add an integer. Type safety wants to ensure that an array of strings is an array of strings. An array of integers, remains as integers.

Attempting to add a string to an array of integers will result in an error. Xcode will even try to give you a hint at what sort of value you should be adding, too.

If you do append an erroneus item to an array, the first part of the error does seem to be a little cryptic compared to some others I've seen in the past.

error: Day_003.playground:64:17: error: no exact matches in call to instance method 'append'
someLostNumbers.append("Something")
                ^

Day_003.playground:64:17: note: found candidate with type '(__owned Int) -> ()'
someLostNumbers.append("Something")
                ^

Day_003.playground:64:17: note: found candidate with type '(__owned String) -> ()'
someLostNumbers.append("Something")
                ^

But, as you work through it, you can kind of see what it's getting at.

What happens if you want to create an array, but don't have anything to put in it yet? Well, this can be done by creating an empty specialised array.

var scores = Array<Int>()

// A shorter way
var scores = [Int]()

If you need to know how many items are in an array, we can use .count.

someLostNumbers.count

There are various ways to remove items from an array. The first, removing one item at a time by its index. Another way it to remove all of the items. By typing .remove in Xcode, I can also see there are many more options.

someLostNumbers.remove(at: 2)
someLostNumbers.removeAll()

How about checking to see if an array contains something? This can be done using .contains.

someLostNumbers.contains(15) // Returns true

Sorting an array can be done by using .sorted

someLostNumbers.sorted()

Finally, for, there is also reversing an array. This can be done using .reversed().

let foundNumbers = someLostNumbers.reversed()
print(foundNumbers)

Doing this doesn't actually return what I'd have expected, but rather something called a ReversedCollection that makes a reference back to the original

ReversedCollection<Array<Int>>(_base: [4, 8, 15, 16, 23, 42])

I don't fully understand how or why this is happening, and will need to look in to this further. It's not the behaviour I expected. Initially, I can see how it could be seen as more optimal as it's not having to do the work of changing it all and saving it again.

• Arrays Review Test: 6/6

Storing and Finding Data in Dictionaries

Reading items from an array using their index isn't always ideal, and could actually cause issues. Swift also has dictionaries, which are based on key/value pairs which let us decide how we want to store the data inside.

They are created in much the same way as an array, but rather than just being a long list of values, you assign keys.

let batmanData = [
    "realName": "Bruce Wayne",
    "base": "Bat Cave",
    "sidekick": "Robin"
]

When trying to return data from the dictionary, Xcode may warn you that you may, or may not, get data back. When it returns the value, it comes back with "Optional".

The solution to this is telling Swift to return another value by default if it can't return something.

print(batmanData["base"])

// If the key doesn't exist, we can tell Swift to return another value.
print(batmanData["realName", default: "Unknown"])

We can also create other types of dictionaries, such as a string/boolean, or an integer/string.

// We can also keep booleans as values - A String/Boolean dictionary
let hasGraduated = [
    "Eric": false,
    "Maeve": true,
    "Otis": false
]

// Or an Integer/String dictionary
var olympics = [
    2012: "London",
    2016: "Rio",
    2021: "Tokyo"
]

print(olympics[2012, default: "Unknown"])

To create an empty dictionary, it would be done like this:

var heights = [String: Int]()

// Add a key and value to the empty dictionary
heights["Person One"] = 229

And finally, dictionaries cannot contain duplicate values. If you were to assign a new value, it would simply overwrite the existing.

olympics[2021] = "Somewhere Else"

• Dictionary Review Test: 11/12

Mistakes:

One of the questions asked if this was valid code. I assumed this was false as I mistakingly thought it was trying to add something to the dictionary. On a second look, I can see that it's assigning a value to a constant, based on what could be in the dictionary.

let capitals = ["England": "London", "Wales": "Cardiff"]
let scotlandCapital = capitals["Scotland"]

Using Sets for Fast Data Lookup

As well as arrays, and dictionaries, there is also sets. They work similar to arrays, but they don't remember the order you added the values, and they don't allow duplicates.

So, why would you use this over an array? You may not want to allow duplicates in your data. Sets are also incredibly efficient in how it stores the data, so returning a result by using something like .contains() will be far faster than if you used an array.

Creating a set is done in a similar way to an array.

// This creates an array inside the set
var actors = Set([
    "Denzel Washington",
    "Tom Cruise",
    "Nicolas Cage",
    "Samuel L Jackson"
])

Adding items to a set is done using insert, rather than append.

actors.insert("Angelina Jolie")

You can also sort a set, which will return an array with your sorted data.

print(actors.sorted())

For a deeper dive on sets, see https://www.avanderlee.com/swift/array-vs-set-differences-explained/

• Sets Review Test: 12/12

Creating an Using enums

Enum, short for enumeration, is a set of named values. We can define types that contain a specific set of values, such as the days of the week:

enum Weekday {
    case monday
    case tuesday
    case wednesday
    case thursday
    case friday
}

Storing things this way is far more efficient, as Swift stores them in an optimised form.

It's also a safer way, ensuring that a wrong value couldn't be assigned.

Enums Review Test: 12/12

Summary

That's it for day 3. The dictionaries review test caught me out on something I should have spotted, but it's coming up to lunch time and I was starting to make some silly mistakes.

It's also taking far, far longer than I wanted to get through the content, and write up a post. Maybe that's a good thing, as it will reinforce what I'm taking in, but it's also making me want to stop already ... at day 3.

Welcome to day 2 of the 100 Days of SwiftUI. If you didn't read day 1, head on over to the post here: https://blog.grayw.co.uk/100-days-of-swiftui-day1. But, in short, I'll be following the 100 Days of SwiftUI from hackingwithswift.com, and documenting my progress here (for as long as I remember to).

If you'd like to follow this series, you can do so by following the tag here: https://blog.grayw.co.uk/tag/100daysofswiftui/

With that out of the way, let's get down to it!

Simple Data Types: Part 2

Today looks like a slightly shorter day than yesterday from the list of topics. It looks like we're going to cover booleans, and joining strings. There's also the first checkpoint of the course.

I'll also be working from the MacBook today, rather than the iPad. I did notice that having a video playing PiP (Picture in Picture) from Safari, did utilise a vast amount of the battery. I may have to keep the iPad for just lighter reading. We'll see.

So, my setup today is using Xcode on macOS in a new Day 2 playground.

How to store truth with Booleans

Booleans store a value of either true or false. Apparently, these were named after George Boole, an English mathematician.

George Boole - Wikipedia

Wikimedia Foundation, Inc.Contributors to Wikimedia projects

We can see the basics of this by creating a variable, and then using the .hasSuffix() we learned about in day 1, to check if the filename ends with a specific string.

In this example, we can see that the filename is wales.jpg, and we're using .hasSuffix() to check to see if it ends with .jpg. This is returning true, because ... it does.

The same also applies for the second example that 120 is a multiple of 3. I will take that as true, because I am well and truly numerically dyslexic. They make no sense to me at all.

Slight Tangent

On the note of numbers making no sense, I did learn about the Japanese method of multiplication a few years ago which made far more sense to me than years of anything else that people tried to drum in to my head.

You can read more about it here: https://www.whizz.com/en-us/blog/how-the-japanese-multiplication-method-works/

Back on Track

Back to Booleans.

Unlike strings, integers, and doubles, booleans do not have a selection of operators as this makes little sense. However, there is one, the !. This will swap the value, as can be seen in the below screenshot.

isAuthenticated starts off as false. We then take that and assign it a new value that is "not" the original value, thereby making it true. Doing the same again, swaps it back and saves that value back to the variable.

Another method is using .toggle(). It achieves the same outcome, but with less code. gameOver starts as false, but by typing gameOver.toggle(), we have swapped the value to true.

• Doubles and Booleans Review Test: 6/6

Joining Strings Together

The second part of today is about joining strings together. There are two ways of doing this. The first is the simplest option. You can use the + operator to join two strings together.

However, this is not the most efficient way of doing things as this causes Swift to create temporary strings as it adds each additional part to it. A good example of this is the luggageCode variable. It will first add 1 and 2 together to make "12", then add the 3, to make "123", and so on.

Something you're unable to do here is + a number in to a string. So the below wouldn't work:

let phoneNumber = 123456789
let message = "Give me a call on " + phoneNumber

However, what you could do is tell Swift to treat the integer as a string instead:

let phoneNumber = 123456789
let message = "Give me a call on " + String(phoneNumber)

This isn't the best way to do this, which brings us to the second way, which is string interpolation.

We can drop other values in to a string by using \(varname) within it. This is much easier to read and understand.

So, for our previous example, we would write it as:

let phoneNumber = 123456789
let message = "Give me a call on \(phoneNumber)"

We can also include things like multiplication inside a string with string interpolation.

print("5 x 5 is \(5 * 5)")

For a deeper dive on string interpolation, I should take a look at https://www.hackingwithswift.com/articles/178/super-powered-string-interpolation-in-swift-5-0

• String Interpolation Review Test: 6/6

Summary of Simple Data

• Swift lets us create constants using let and variables with var. Constants should be used when possible.
• Swift's strings contain text. This can be whole words, sentences, paragraphs, or more. These are created by using double quotes at the start and end, or """ at the start and end on their own line for multi-line strings.
• Storing whole numbers are done with integers - Int
• Storing decimal numbers is done with double - Double which is short for Double Point Floating Numbers. These are not 100% accurate.
• Int and Double's have a range of arithmetic operators
• You can store simple true or false values with Booleans - Bool
• String interpolation lets us place data in strings efficiently and easily.

Simple Data - Checkpoint 1

At checkpoint 1, we're asked to create a playground that achieves the following:

• Creates a constant holding any temperature in Celsius
• Converts that temperature to Fahrenheit by multiplying by 9, dividing by 5, then adding 32.
• Prints the result, showing both the Celsius and Fharenheit values.

Below is my solution.

let celsius = 13
let fahrenheit = celsius * 9 / 5 + 32
print("The current temperature is \(celsius), which is \(fahrenheit) in Fahrenheit.")

This returns the string:

The current temperature is 13, which is 55 in Fahrenheit.

In this checkpoint, I have created two constants. One with an Integer, and the second using the first, using operators to create a second Integer. I then used string interpolation to return a string with data in it.

How did this differ from the solution in the video? Well, first was that I should have used a decimal number for the temperature. I had no inclination to show .x in the temperature.

The second was that I could have used Option+Shift+8 to get the ° symbol to use in the string.

If I were to re-write it to line up with that, I would do it like this:

let celsius = 13.0
let fahrenheit = celsius * 9 / 5 + 32
print("The current temperature is \(celsius)°, which is \(fahrenheit)°F.")

This returns the string:

The current temperature is 13.0°, which is 55.4°F.

Summary

Thanks for following along in with day 2. I hope you'll join me for day 3.

In an effort to improve myself, I have decided (after much, much back and forth) to attempt to learn Swift.

I spend my day managing both Apple and Windows devices. The majority of my time is spent around macOS, and iOS. However, I also spend quite a lot of time deploying Windows-based devices too. I've also had a few app ideas i've been wanting to create for a number of years.

After much self-debate, I finally decided that Swift would be the best option, as I spend more time in the Apple world than the others these days. Not only will it allow me to create the apps I want, but it could also have a positive effect on the things I'm able to achieve in work, too. Unfortunately, this won't help me on the Windows side, but, I can also do enough PowerShell to be dangerous, and have tools such as Microsoft Endpoint Manager to make my life easier.

So, feel free to follow along as I learn SwiftUI, and see what I make, or if I can even make it to day 100. It wouldn't be the first time I've done 100 days of something - check out my 100 Days to Offload post series! https://blog.grayw.co.uk/tag/100daystooffload/

As I can already do some basic things with PowerShell, there are going to be parts of this course that are immediately obvious, but I'll be treating them as if I know nothing. So you'll need to bare with me (or skip ahead if you're reading this later on in the course).

Less blabber, on to the content!

The Workspace

Due to my job role, I've got a few devices I can work with here. Both a MacBook, and an iPad (yes, I'm lucky, and grateful). As long as it doesn't interfere with my day to day work, I'm able to experiement with these devices as I wish.

With the recent release of Swift Playground 4 - I will probably be using that as much as possible, rather than the full blown Xcode on the Mac. This will allow me to be far more flexible on when and where I'm learning (I'm looking at you, porcelain throne).

I've created a blank plaground to start the basics.

Variables & Constants

The first main part of day 1, is the creation of variables and constants.

Variables are created by using the var keyword, followed by the name you wish to give the variable, an = sign, and then the content.

var greeting = "Hello, Readers!"

Variables can be re-assigned a new value as often as needed, but you only need to use the var keyword once. After that, simply use the name of variable.

In the above, you can see that I've created the greeting variable, and assigned it the value of "Hello, Readers!". Not quite the typical "Hello, World", but it's close enough!

After that, I create a variable called catName and assign it the value of Nuts (yep, that's the name of one of my cats). I then change the value to the name of my other cat. So, what does this do?

If I add in a few lines to "print" the variable contents, I can see how they're returned.

Variables can contain all manner of contents, but we're sticking with simple examples for now.

Next up is Constants. Their value cannot be changed once assigned. If you attempt to change the value, you will receive a warning, and the code will not run.

When possible, you should use a constant over a variable, as this allows Swift to better optimise your code, and, more importantly, stops you from changing the value by mistake.

The names of variables and constants are case sensitive, and generally created using the camelCase naming convention.

• Variables Review Test: 6/6
• Constants Review Test: 6/6

Working with Strings

So far, all of our variables or constants have been strings. There are a number of things we can do with them. This is just a couple of very basic examples.

This first is using "" within a string. To do this, you need to use the \ symbol to escape that character, otherwise Swift will show an error, as it thinks the string has ended, and there is now contents after it that shouldn't be there.

Next is a multi-line string. These are rarely used, but should you need to use one, then they start with """, with your text on new lines, ended with """ on the last line.

You can get the length of a string by using .count. In my example, I printed the length of catName, which returned 6. You don't have to print this directly, it can be assigned to another variable/constant, and then used later.

Another example is converting the entire string to uppercase by using .uppercased()

And finally, you can also check strings to see if they start with (prefix), or end with (suffix) specific words or characters. This is done by using either .hasPrefix() or .hasSuffix(). Both of my examples return true, as it matches. It's important to keep in mind that this is case sensitive. So, if my last example was:

print(longString.hasSuffix("INSIDE."))

This would return false. As that's not how the string ends.

• Multi-line String Review Test: 12/12

Working with Whole Numbers

Working with integers as variables or constants is just as easy as it is with strings. You use the var/let keywords, followed by the name, and then the value. If the number is really long, you can use _ to break it up, and make it easier to read. Swift will ignore these, and display the number as it should be.

You can also do the obvious things, such as addition, subtraction, division, etc. There is also a way of checking to see if a number is a multiple of another, by using .isMultiple(of: number).

• Working with Whole Numbers Review Test: 6/6

Working with Decimal Numbers

Swift also has the ability to work with decimal numbers, also known as floating point, or doubles.

You can do the same kind of  things with these, however, at this very basic level, there are things you need to be aware of, and you may not get the result you were expecting.

For example,

let floatingNumber = 0.1 + 0.2

This will not return 0.3 as you might expect, as you can see in the below screenshot.

Swift also classes integers and decimals as different types. So, you can't add an integer to a double, or vice-versa. Unless you tell Swift to treat one number as the other.

let numberA = 1
let numberB = 2.0
let numberC = numberA + Int(numberB)

Type Safety will also step in if you try to change the type of variable. For example, changing a string to an integer.

Summary

That's the end of the content for day 1 of Hacking with Swift's 100 Days of SwiftUI. As things progress past these first few basic concepts, I'm sure you'll start seeing me make stupid mistakes, but hey, isn't that a part of learning?

If you'd like to join in, head over to https://www.hackingwithswift.com/100/swiftui and follow along.

Hopefully, by making this initial post, it will hold me accountable to making progress each day (Hah!).

If you've ever had the misfortune of having to manage the deployment of Adobe applications at scale, then you'll most likely be well aware of the Adobe Update Server (AUS) and the Adobe Update Server Setup Tool (AUSST).

What is AUSST

In an enterprise environment, you usually have many users who require various Adobe apps and updates. Each user is required to download and install the apps individually. Allowing all your end users to individually download and install apps from the Adobe servers will consume a sizeable amount of network bandwidth in your organization.

To address the issue of network bandwidth consumption, Adobe provides Adobe Update Server Setup Tool (AUSST). AUSST enables you to centralize the download of Adobe apps and updates to a server location.  After implementing AUSST, you can redirect your end users to download the Adobe apps and updates from the internal update server. This way, a single download from the Adobe servers is required for each app or update.

– Shamelessly copied from https://helpx.adobe.com/enterprise/using/update-server-setup-tool.html

Sounds like a really useful tool, right? Wrong. If it's not something you've ever had to deal with, continue to pray you never have to lay hands on it. The Adobe forums are plagued with people asking why it does things, and why it doesn't. There are countless threads where Adobe "support" answers once or twice, suggests you contact them directly, and then proceed to ignore you for eternity. It provides an intermittent, unreliable service at best. I guess they're keeping it in line with all of their other products and services ...

The Problem

As with most companies, recent times dictated that many of our employees began working from home. This now meant that all of those devices that were configured to contact our internal update server for Adobe updates were now hammering back over the VPN resulting in the following:

Internal Update Server - Downloads updates (if you're lucky)
Client requests update
Overrides point to internal server
Client connects to internal server over VPN
Client downloads update from internal server

On an internal network without the VPN, this would be fine. But now we're just wasting resources. Not only that, but if your internal server is having a moment, then your clients aren't going to receive the updates, as they won't query Adobe directly.

And that server moment is precisely the thing that's happened. Again. Despite the permissions being correct, and the content being available on the server, it's returning 404's and 401's to the client requests. My only remaining option is to completely rebuild the server and start from scratch. But I've got clients that need updates now to mitigate CVE's that affect us.

The Solution

So, what can you do when your internal server isn't available? Well, according to Adobe, you make sure you tick a little box when creating the overrides on the admin dashboard - https://helpx.adobe.com/lt/enterprise/using/update-server-setup-tool.html - "What happens if your internal update server is down" (because who wants anchor links ...)

Well, that seems simple enough. But wait a minute, how are my existing clients going to know about this change if the package has already been installed (package and overrides were created by someone else). I'm not being prompted to change the configuration on the server, because it's "down", and the overrides file on the machine is telling it to get the updates from adobeupdates.yourdomain.com (please note: this is probably a really, awful idea, especially if it's available externally without a VPN).

After ticking that box, I diffed the override XML. To my complete lack of surprise, nothing had changed. I generated a new installer package, and after searching for far too long, I finally found the reference to the bypass.

Hiding in a file named Binary.optionXML, there's a section with the following:

<feature>
  <name>AdobeFallbackForAUSST</name>
  <enabled>true</enabled>
</feature>

All I needed to do next, was find out where this particular block needed to be added. After more searching and file content indexing, I found that the other settings stored with this block are in the ServiceConfig.xml file. This can be found in the following location

Windows: C:\Program Files (x86)\Common Files\Adobe\OOBE\Configs\
macOS: /Library/Application Support/Adobe/OOBE/Configs/

Insert the fallback block in to this file somewhere and save it. It will probably look a little something like this:

<config>
    <panel>
        <name>AppsPanel</name>
        <visible>true</visible>
    </panel>
    <panel>
        <name>FilesPanel</name>
        <masked>false</masked>
    </panel>
    <panel>
        <name>MarketPanel</name>
        <masked>false</masked>
    </panel>
    <feature>
        <name>SelfServeInstalls</name>
        <enabled>true</enabled>
    </feature>
    <feature>
        <name>BrowserBasedAuthentication</name>
        <enabled>false</enabled>
    </feature>
    <feature>
        <name>SelfServePluginsInstall</name>
        <enabled>false</enabled>
    </feature>
    <feature>
          <name>AdobeFallbackForAUSST</name>
          <enabled>true</enabled>
    </feature>
</config>

After you've made this change, you'll need to restart the machine. Restarting the Creative Cloud Desktop application didn't seem to have any affect. Probably due to the disgusting number of processes it holds open in the background, despite being "Quit". Trying to end all of these manually just isn't worth the effort.

Deploying the Fix

If this works for you in test, then the only thing left to do is to deploy the change to your devices. I felt that this would be easier than re-creating packages and deploying those out, due to the vast difference in file sizes. You should always consider that some users may have bandwidth / usage caps. ~5 KB file rather than a few hundred MB is far easier to manage (yes, the Windows Creative Cloud Desktop App is almost 800 MB by itself).

With the majority of our Windows-based devices now being co-managed via Intune ... Sorry, Microsoft Endpoint Manager, I'll be pushing the file out as a Win32 app. This allows me plenty of control to make a copy of the existing file while copying the new file to the locations required.

For our macOS-based devices, I'll be pushing that out with Jamf. I'm not sure which method I'm going to use for this yet. I'm torn between creating a package with the new file in it, or using a combination of a script to make the copy, and then pull the updated file from an internal repo.

On typing that, and with a few minutes reflection. I think I will create a package with the file, and a preinstall script to make a copy of the old one before "installing" the new one.

Pro's & Con's

Doing this may not be an option for everyone, especially if you need to tightly control the versions that are being deployed within your environment. But for those of us who were just trying to save on data costs from within the network, this may be an option.

By doing this, you are telling the client to reach out directly to Adobe in the event that your internal server isn't contactable. You could then block access to your server via the VPN, ensuring that anything physically outside your network will contact Adobe directly. Those still inside will attempt to download from the server first.

• Pro - External users are no longer hammering the VPN tunnels with Adobe updates
• Pro - In the event that your internal update server is down, clients can still download their updates and stay up-to-date with patches
• Pro - Smoother experience for the end user
  
• Con - Loss of control over deployed versions
• Con - If your internal server is down, your internal devices could potentially give your connection a beating

Even that second con isn't necessarily a forgone conclusion. Anything that physically remains inside your network, such as a desktop, could always be excluded from receiving the new file.

Important: Keep in mind that any future packages generated via the admin portal will contain this fallback option.