Gunther Kochmann

Thoughts on how to setup and organize more complex Property Manager (PM) configurations

Blog Post created by Gunther Kochmann Employee on Jun 23, 2015

Were you ever wondering whether there is any best practice when it comes to setup of an Akamai configuration in Property Manager that handles more than one hostname?


For this simple case (e.g. one hostname/origin) you might have used either the PM Wizzard or simply clicked yourself through the different preprared sections of the PM template for your product. However, Property Manager is capable of much more and may be used to setup a single configuration that can handle tens or even hundreds of hostnames with different origins and CP codes plus complex caching rules - while benefit of advanced features comes on top.


If you're new to this area or have never dared to extend your configuration for your many other sites and usecase, the following might give you some hints and hopefully encourage you to leverage more of Property Manager's features.


  • Start by creating a new property (I am presuming everyone's done that before)
  • To start with, add all your hostnames ideally by 'Add Bulk Hostnames'




  • select one Edge Hostname for all (easier, if feasible for your setup) and enter all hostnames in the text field, then click 'Add Hostnames'




  • now click on 'Default Rule' and enter all default configuration details, like default origin, CP code, origin SSL certificate information (if applicable)
    • recommended is to keep 'Caching' to 'No Store' as default and define in a later stage which objects may be cacheable
    • enable/provision all your available features like SureRoute, Tiered Distribution, Prefetch, POST requests, logging information, Real User Monitoring, cache key settings, caching of HTTP error responses, etc. (availability depends on the product you use and your contract)
    • if you make want to make use of Cloudlets (like Edge Redirector, IP/GEO Access Control, Forward Rewrite, Image Converter or Visitor Prioritization) and the respective Cloudlet shall be applied globally to all requests add it to the Default Rule as well
  • in case you do not want to apply a Cloudlet globally (to all requests) you better enable your desired Cloudlet within a match, e.g.
    • if requests for a certain hostname shall be processed by a cloudlet, enable the Cloudlet within a section like the hostname to origin rules (refer below)
    • if requests for certain objects by file suffix shall be processed by a cloudlet, setup a group where cloudlets are selectively enabled
      • create a new Blank Rule and name it 'Cloudlets'
      • create a new child rule (use the arrow next to Add Rule') under this 'Cloudlets' rule (use the Blank Rule Template) and name it 'Image Converter' (as an example)
      • use Criteria 'File Extension' and put for instance JPG, GIF
      • under Behaviors select 'Image Converter' Cloudlet
      • create another child rule under this 'Cloudlets' rule (use the Blank Rule Template) and name it 'Edge Redirector' (as an example)
      • use Criteria like 'Hostname' and put all your hostnames where Edge Redirector shall be enabled for
      • under Behaviors select 'Edge Redirector' Cloudlet and enter the name of your policy to apply here (for the sake of this example we presume that you have created this policy before




  • next create a new blank rule and name it 'Hostname Configuration'
    • below this rule create a new rule for each of the hostnames on the configuration
    • Criteria shall be a match on Hostname (select one each)
    • Behaviors would be at least 'Origin' and 'Content Provider Code'
    • optionally you may enable a certain cloudlet for individual cloudlets (if not already done globally)




  • in the same fashion as the hostname configuration group was setup, it is advised to make a group for rules related to caching
    • create a new blank rule named 'Caching Rules'
    • start by moving the caching rules (e.g. Static Content, Dynamic Content) under this newly created rule (drag and drop works)
    • create child rules for each and every other required caching rule
      • for example if you would like to make all objects under the path /download/content/ cacheable for 7 days
      • Criteria shall be a match on 'Path'
      • Behaviors would be Caching, Prefetch (disable) and Prefetchable Objects (enable)




  • now we come to additional features like control of downstream cacheability (multiple options exist, this is an example only)


  • if you decide to provision redirects at the Edge (not via your origin or Akamai cloudlet), it is advised to create another group for all those redirects (e.g. called 'Edge Redirects')




Many features and aspects exist on top of that, but that highly depends on the scenario or use-case that this configuration shall serve for. In the end this chain of suggestions may be continued forever. Other ideas of functionality to build in could be A/B Testing, Large File Optimization or the way Akamai treats query strings or where query strings control the behavior.


I would like to highlight that the grouping which I have explained here is mainly for ordering the configuration and making it better readable. Reason for that is that you may minimize a whole group, which means that all elements of a group are not shown when minimized. Especially for a large number of hostname, caching or redirect rules this helps a lot.




In case you have already got your (basic) configuration and would like to extend it in a similar fashion (more hostnames, redirect rules, etc.), you may simply start with that one and create all the grouping elements and then drag and drop the respective elements into those groups for better overview of your configuration. Then you're ready to go with adding further elements!


Does this help you in setting up more advanced Property Manager configurations?


Do you have any use-cases that you are wondering how to implement in Propery Manager but are unsure how? Please report, me or the Luna User Community may help.