Our company deals exclusively with the education market. While we remain vendor agnostic, I'm a big fan of the FortiGate - and several of Fortinet's products - in an educational setting and I recommend them whenever I think they're appropriate.
Here's an abbreviated version (focusing on content filtering) of our internal guide:
First and foremost, we always speak to administration about their needs and expectations. We also explain the practical limitations of the device and try to temper expectations. Suffice it to say, there have been many times when administrators have come to us in a panic: "How were students able to get onto this inappropriate site? We just spent $xx,xxx on this device, isn't it supposed to block everything?" Conversely, we deal with many schools who don't mind certain sites being accessible by students that others would want blocked. We use administration's guidance to build our content filtering policies.
Second, we always establish a logical organizational map of user groups and who should have access to what. We will use this for our group mapping.
Third, and this is optional, we recommend to our client that they have some sort of client management/MDM solution in place. While this doesn't directly affect perimeter security and content filtering, it's especially useful for distributing certificates when enabling deep SSL inspections. If you're a homogenous Windows environment, you can get by pretty well with GPOs. Likewise, you can do basic certificate pushes with Apple's Profile Manager for your Macs.
Fourth, we find out how users are accessing the network and determine how we will identify them. By now, we have created our groups in the FortiGate and mapped them accordingly to our LDAP environment.
For Windows clients bound to AD, you can have the FortiGate poll your domain controllers or retrieve logon info from the aggregate collector on a Windows machine that can be configured to either poll your DCs or install an agent. You may not like the idea of an agent on your domain controllers, so polling should suffice in many cases. We also found that polling is a must if you have Mac clients.
For clients connecting wirelessly and authenticating via RADIUS, enable the RSSO collector agent on the FortiGate (and configure the groups accordingly) and have your RADIUS server forward accounting packets to it. This works just fine with Microsoft's NPS.
If you're connecting non-AD-bound wireless devices and aren't using RADIUS authentication but want to apply content filtering policies, you'll either need to register individual devices into groups (which becomes inefficient and unwieldy for all but the smallest environments) or create a VLAN for wireless devices and use the FortiGate as the VLAN's gateway with captive portal enabled. The idea is to have a user login mapped for every device that accesses the network whenever possible. Using FortiAPs for your wireless network can make this process somewhat easier, but this is not always realistic.
Lastly, and depending upon your needs, have a look at the FortiAuthenticator. Think of it as the "professional" version of the FortiGate's SSO/authentication features. For example, it allows for users to register their BYOD devices via a self-service portal.
Best of luck!