[upbeat music]
Kimberly Trojanowski: Good morning.
Today, I'm sharing my story of the process
we used to move our Jamf Pro instance
from on-premises to the cloud.
My name is Kimberly Trojanowski,
and I work at the School District
of Waukesha, in Waukesha, Wisconsin.
I'll begin by explaining
why we moved to the cloud,
by what we did to prepare for the move,
what occurred on moving day,
and finally, what needed to be done
after our cloud instance
was up and running.
When we first started using Jamf Pro,
known as Casper Suite, at the time,
we had ten iPads that were purchased
for use by our special ed department.
We set up one Windows server
that ran our Casper instance and MySQL.
We gradually purchased more devices,
and eventually, the district chose to use
Apple devices for our one-to-one program.
By the time we finished deploying
all of the devices,
we went from ten iPads to over
1,400 devices and 1,400 computers.
Our server setup went from one server
running everything to three servers
running Jamf Pro,
one primary and two web app servers
behind a load balancer,
A separate server running MySQL,
and eventually two Mcache servers.
Now, we are in the cloud.
And this is how we got there.
We began the process by scheduling a call
with a professional services engineer
assigned to assist us during the move.
During the call,
we discussed our current environment.
I sent him a Jamf summary
of our environment.
I asked any questions
I had about the process,
and we set a cutover date.
Finally, after the call,
I notified staff members
of the schedule cutover date.
During the call, the engineer recommended
that we clean up
any unneeded items in our database.
I went through
and looked at our policies,
groups, saved searches, apps, eBooks,
and deleted any of these
that were obsolete for whatever reason.
I then cleaned up the items in Jamf Admin
and our file share distribution point.
I deleted any obsolete packages,
doc items, printers,
and scripts from Jamf Admin.
After the cleanup of Jamf Admin,
I then deleted the unneeded packages
and eBooks
for our file share distribution point.
If the file share distribution point
is located on an in-house
Windows server,
and a package is deleted from Jamf Admin,
it doesn't remove the file
from the distribution point.
I could have skipped this step,
since eventually the distribution point
wouldn't be needed,
but I like to be thorough.
A couple weeks later, it was moving day.
That morning, I sent an email
to staff reminding them of the outage.
Then, that afternoon,
at our scheduled move time,
I connected tot the WebEx meeting
our engineer had set up.
Once connected,
I flushed our log files in Jamf Pro
and sent a Jamf summary to our engineer.
He reviewed the summary,
to make sure that there weren't
any significant changes in our database
from the original summary I sent him.
Basically, he wanted to make sure
that the status of the database
hadn't grown unexpectedly.
I then disabled Tomcat
on our three web app nodes
and set the service to disable,
instead of automatically start up,
just in case one of our servers
was accidentally restarted
by another member of my team.
Our network admin then added
the CNAME records for our new instance
given to us by our engineer.
Then we had time to back up the database
and upload it to a Jamf drop box.
Our engineer received the database backup
and sent it to the cloud team,
and we waited for them to do their magic.
After the engineer received notification
from the cloud team
that our new cloud instance was ready,
we completed the final steps of the move.
I logged into Apple School Manager,
created a new MDM server,
downloaded the token for the server,
and then uploaded it to Jamf
for automated device enrollment.
I then edited our pre-stage enrollments
to look at the new automated
device enrollment instance.
We tested enrolling a few devices,
installing printers,
and verified scripts still work.
And then,
since we have a connection to GSX,
to look at purchasing information,
I needed to upload a new GSX token.
The last step that day was to shut down
the servers that weren't needed anymore.
This included the Mcache servers,
the database server, and the primary node.
That left us with two file
share distribution servers still running.
A few weeks after the move,
when I was sure that everything
was stable in our environment,
I replicated our packages
to the new cloud distribution point.
I made it the primary distribution point.
Then I modified each package policy
to point to the cloud distribution point
and deleted the file
share distribution point from Jamf.
Since these were Windows servers,
as a security measure,
I also disabled the AD account
that was created with a shared folder.
Once that was done, I shut down
our backup file distribution share.
Besides serving as a file
distribution point,
our remaining server
contained our in-house eBooks.
Before the server could be shut down,
[inaudible]
each eBook to the database.
To do this, I had to delete
each eBook entry in Jamf
and then re-add them.
Changing location within the entry
wasn't an option.
Once this was done,
I was able to shut down our final server.
Our Jamf Pro instance
is completely in the cloud now,
and with a little planning,
the move from on-premises to the cloud
was much easier than I expected.
I hope you enjoyed my presentation,
and thank you for listening.
[upbeat music]