Planning for Cache in Sitecore

This is a follow-up to my Unofficial Sitecore Planning Checklist, where I try to consolidate as much information as I can find on Sitecore’s built in caching.

One of the easiest ways to improve a visitor’s perceived impression of any website visit is through a well-tuned cache. A cache which has been properly tuned will be able to server of requested content quicker, sometimes magnitudes faster than rebuilding the HTML for a page on each request.

Sophisticated caching scenarios can be configured through third-party tools and applications, but even for the most highly trafficked site properly tuning Sitecore’s different cache options should provide the desired performance gains. As site cache is configured and tuned, be aware the need for vertical or horizontal scaling may become necessary. (For details on scaling Sitecore checkout Scalability)

Determine the cache limits required

The general practice for Sitecore caching tuning is to turn all cache limits off via the following simple cache patch config:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <settings>
      <setting name="Caching.DisableCacheSizeLimits">
    <patch:attribute name="value">true</patch:attribute>
    </settings>
  </sitecore>
</configuration>

With the cache limits now disabled, Sitecore will try to manage based on current traffic and available resources to cache as much as possible. By performing well structured load test or allowing the site to run in this manner, the team should monitor both server resource utilization as well as the Sitecore cache levels to determine areas that should be manually limited to maximize performance.

To monitor what Sitecore has cached you can use the Sitecore admin page, http://&lt; your domain >/Sitecore/admin/cache.aspx, or leverage the Sitecore Marketplace module Caching Manager, https://marketplace.sitecore.net/en/Modules/Caching_Manager.aspx.

Cache Manager Options

After data collection has occurred you are ready to begin to evaluate which caches need their limits adjusted from the default level. For more information on the different cache limits that can be set see Sitecore CMS 7.0 – 7.2 CMS Performance Tuning Guide.pdf and Sitecore CMS 6.6 or later Cache Configuration Reference.pdf.

Configuring HTML Cache of Components

The first level of caching to configure to is review each rendering that is created and set the appropriate HTML level caching on it.

Rendering Cache Option

To turn HTML cache on for the rendering, select the first option Cacheable. From here you can customize the how different variations of the control should be cached via the different ‘Vary By’ options. Finally, you can mark that all cache be cleared when the search index is updated via the ‘Clear on Index Update’ selection.

The following fuller description of each cache option is taken from Chapter 4: Output Caching in Sitecore CMS 7.0 or later Presentation Component Reference.pdf.

Clear on Index Update

The Clear on Index Update property controls whether or not a control clears its cache when an item that is associated with the control is updated in the index. This is useful for any control that uses the new Search API to populate its data sources. For example:

  • You have a control that returns all the products that are on special offer from the index.
  • The Clear on Index Update property for this control is set to True.
  • The price of each product is stored in the index.

If someone updates the price of one of the products on special offer, the Clear on Index Update property will the trigger the control to clear its cache because something has been updated in the index that is bound to the control.

VaryByData

The VaryByData property controls whether or not output caching varies based on the data source of the presentation component.

Set the VaryByData property:

  • To False for components that do not generate different output when used with different data sources.
  • To True for components that generate different output when used with different data sources.

VaryByDevice

The VaryByDevice property controls whether or not caching varies based on the name of the context device.

Set the VaryByDevice property:

  • To False for components that do not generate different output when used with different devices.
  • To True for components that generate different output when used with different devices.

VaryByLogin

The VaryByLogin property controls whether or not output caching varies based on whether or not the user has authenticated. For caching configuration involving the VaryByLogin property, the layout engine treats all anonymous users as a single authenticated user.

Set the VaryByLogin property:

  • To False for components that do not generate different output for authenticated than for unauthenticated visitors.
  • To True for components that generate different output for authenticated than for unauthenticated visitors.

VaryByParm

The VaryByParm property controls whether or not output caching varies based on rendering parameters passed to the presentation component. Solutions built with earlier versions of Sitecore may have used the token VaryByParam instead of VaryByParm. Update any instances of VaryByParam to VaryByParm.

Developers set the VaryByParm property:

  • To False for components that do not generate different output when passed different rendering parameters.
  • To True for components that generate different output when passed different parameters.

VaryByQueryString

The VaryByQueryString property controls whether or not output caching varies based on query string parameters passed in the URL. The VaryByParm property causes output caching to vary based on rendering parameter values passed by the developer. The VaryByQueryString property causes output caching to vary based on parameters passed in the URL query string.

Developers set the VaryByQueryString property:

  • To True for components that generate different output when supplied different query string parameters.
  • To False for components that do not generate different output when supplied different query string parameters.

VaryByUser

The VaryByUser property controls whether or not output caching varies by the domain and username of the context user.

Developers set the VaryByUser property:

  • To False for components that do not generate different output for different users.
  • To True for components that generate different output for different users, when the number of active users between publishing operations is relatively small. The VaryByUser treats all anonymous users as a single authenticated user.

To avoid excess memory consumption, avoid using the VaryByUser property except in solutions with relatively small numbers of users, or monitor cache utilization closely. The VaryByLogin property causes Sitecore to generate different output depending based on whether or not a user has authenticated, differentiating anonymous users from authenticated users. The VaryByUser property causes Sitecore to generate different output for each user

Other Caches

Sitecore contains a number of other caches that help to lower the number of calls required to the database for item information and indexes. These are best described in a post from the Sitecore Tactics blog entitled How Sitecore caching work.

Additional Helpful references

One Final Note

Starting in Sitecore 8.2, the Cache APIs where refactored, creating breaking changes to any custom cache providers used in previous versions. Be sure to check out the change list, https://doc.sitecore.net/sitecore_experience_platform/developing/developing_with_sitecore/cache_api_changes.

 

Advertisements

SharePoint 2010 SP1 Not Installed

The past few weeks I have been working n scripting out the installation and configuration of SharePoint 2010 and all the services for a multi-server environment. I’ll be posting the details of the script in the coming weeks (okay most likely months….)

For the installation I have been using a slip-streamed set of media which includes SP1 and the June 2012 Cumulative Update. I farm will be using a SQL 2012 database which also provides the advantage of using the new BI features such as PowerView and SSRS as an actual service to SharePoint.

Everything seemed fine until I tried to configure PowerPivot and received a message saying “SharePoint 2010 SP1 is not installed on this machine.” This seemed odd as I’ve been able to configure everything up to this point….

After a few days of googling I finally got the correct search terms, which was “powerpivot error SharePoint 2010 SP1 is not installed”. This led me to a post by Jeff Jones blogger of www.spjeff.com. He has a create article which solved my problem called “Fixed -SharePoint 2010 SP1 is not installed on this computer.

The basic issue is that a registry key does not get updated with the new build version, causing PowerPivot to think everything is out dated. The registry key in question is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\14.0\BuildVersion.

Since I like scripts here is a little PowerShell goodness to help you out. Be sure that the Microsoft.SharePoint.PowerShell snap-in has been loaded into your PowerShell session before running.

$currentKey = Get-ItemProperty "hklm:\software\microsoft\office server\14.0\" -Name BuildVersion
$farmBuild = (Get-SPFarm).BuildVersion
Write-Host "Registry Build is $($currentKey.BuildVersion)"
Write-Host "Farm Build is $farmBuild"
if($currentKey.BuildVersion -ne $farmBuild)
{
Write-Host " - Updating registry build to $farmBuild"
Set-ItemProperty "hklm:\software\microsoft\office server\14.0\" -Name BuildVersion -value $farmBuild
}

Installing SharePoint 2010 with Local User Accounts

This morning I awoke early to a lovely fall-esque morning, bright sun, clear sky, and just a little chill to the air…you never would have thought it was mid-August.

So a beautiful morning, mixed with a delightful cup of coffee (Wegman’s Cinnamon Nut coffee blend) seemed like the perfect fit to write an article on how to install SharePoint 2010 on a local virtual machine with domain connections for development.

So gather you cup of choose beverage ( I recommend a Bell’s Double Creamy Stout for an evening session of install, but I’ll leave that for you to decide) grab the machine of choice and let us begin.

I can’t claim to know it all, and have borrowed the notes made by Neil ‘The Doc’ Hodgkinson in his article from October 19, 2009 found at, http://sharepoint.microsoft.com/Blogs/fromthefield/Lists/Posts/Post.aspx?ID=112.

My first time attempt at performing an advance install of SharePoint 2010 on a single machine, I ended up with the following error message:

clip_image002

(For the search engine: The specified user <local user> is a local account. Local accounts should only be used in stand alone mode.)

So reading this message, I then uninstalled and tied again, but this time using the Stand Alone option given at install time. Well, this worked…BUT you end up with a special SQL Express version installed on your machine, and no control over what user accounts are performing what actions. This was not ideal for me, nor did it give me the additional practice of SharePoint farm installation that I was seeking.

So enough of the small talk…onto the How To!

  1. The first step is to plan out the appropriate user accounts that will be needed throughout the installation process.
    • Based on guidance found in MSDN and the SharePoint Getting Started Guide (http://www.microsoft.com/downloads/details.aspx?FamilyID=3ba69d42-65a2-48fb-88d9-814034874498&displaylang=en) there area number of different user accounts that can be created and assigned to different tasks, in general I would recommend creating the following three accounts.
    • SQL Server Service Account
      • Purpose: Default account used to run the SQL Server services
    • Setup User Account
      • Purpose: Runs the Setup, SharePoint Products Configuration Wizard
      • Specific Requirements: Must be part of the Administrators group, and have read/write access to the SQL server. In addition this account should have db_owner rights in SQL so that PowerShell can be leveraged to get around the noted local account issue.
    • Server Farm and Database Access Account
      • Purpose: Configure and manage the server farm and acts as the app pool identitiy for Central Administration.
  2. Place the DVD into your system or mount the ISO you have. The following opening screen shall come up. Click Install software prerequisites to begin with to confirm all the needed items are installed.
    • clip_image004
  3. This is the opening screen to the prerequisite checker.
    • clip_image006
    • Click Next
    • This will run for about 10 minutes depending on what will need to be downloaded and installed. It is possible to pre-download the above items and install before running the pre-requisite checker.
  4. Click Finish. You will be returned to the opening screen.
    • Click Install SharePoint Server
  5. Enter your Product Key and click Continue.
  6. You are now prompted to either perform a standalone or a server farm install.
    • clip_image008
    • Select Server Farm. Stand alone will create the local SQL version, etc…
  7. Under the Server Type options, you should select Complete as it provides the ability to properly customize the installation.
    • clip_image010
    • Click Install Now
  8. Once the installation completes, you will be asked to launch the Configuration Wizard. DO NOT just blindly click Close. Uncheck the box that says "Run the SharePoint Products Configuration Wizard now." If you don’t the local user account error message will be displayed.
    • clip_image012
  9. Exist out of the Install screen by clicking Exit.
  10.   Now the product is installed, but nothing has been setup and configured. Why? Because we have delayed the running of PSConfig so that we could use local user accounts, instead of being attached to a domain controller.
    • This is were Neil’s blog article comes into play. His article can be found at http://sharepoint.microsoft.com/Blogs/fromthefield/Lists/Posts/Post.aspx?ID=112.
    • SharePoint 2010 has been integrated into PowerShell with a collection of administration cmdlets, more on this in future posts, some of which we are use to seeing as part of STSADM, and even some new ones.
    • For our issue we will need to use New-SPConfigurationDatabase cdmlet. This cmdlet creates a new configuration database on the designated SQL server, for a SharePoint Farm.
  11.   From the start menu open SharePoint Management Shell running it as Administrator this is required even if you are logged as a local administrator….this is a PowerShell prompt, with the SharePoint modules included, and enter New-SPConfigurationDatabase at the prompt and hit enter.
  12.   You will then be asked to enter the required information for a configuration database.
    • clip_image014
    • When prompted for the Farm Credentials make sure to include your machine name as the domain for the account and to enter the password. Passphrase is the password used of the login account.
    • If you receive any error messages, close out of the PowerShell console, delete the Admin and the configuration databases, if they exist, and try again. It does seem to take a few minutes for the process to complete.
  13. Once this succeeds launch the SharePoint Products Configuration Wizard. You will not get the normal opening screen, as we have already created the farm information via the above PowerShell cmdlet.
    • clip_image016
  14. Since the farm has already been created you will be shown the current farm settings. Make sure "Do not disconnect from this server farm." and click Next
    • clip_image018
  15. You will now be asked to configure the necessary settings for the Central Administration Web application for the new farm. Feel free to assign a new port or accept the default, just make sure to take note of what it is. As we will be using local user accounts through out this setup, NTLM is the preferred security setting.
    • clip_image020
  16.   After clicking Next, you will be given a chance to review the settings for the farm. If everything looks correct, click Next.
    • clip_image022
  17. Configuration will now begin, the green processing bar will fill back and forth completing the 9 tasks of SharePoint configuration. Upon completion of the 9 configuration tasks, you should see the "Configuration Successful" screen. Click Finish and the CA should appear.
    • clip_image024

PowerShell v2 ISE and Windows Server 2008 R2

After I have gotten my SQL Server installed, I decided the next step in building out the environment was to add some local users with different permissions for services and testing.

Instead of going through and manually clicking to add each of these new users, I decided why not learn a little more PowerShell. So the first thing I did was go to the ‘start globe’ (I know it is not the start menu, but the official/proper name escapes me plus I like the sound of ‘start globe’) and entered ‘PowerShell ISE’ in the search bar…..a few second later nothing, no results.

Since I was more concerned with developing, I went out and downloaded PowerGUI (http://powergui.org). Well, I have returned to the issue really wanting to use the built in ISE that is provided, so with some better googling I found an article on TechNet (http://technet.microsoft.com/en-us/library/dd759217.aspx) which provides an overview of the ISE for Window Server 2008 R2.

The article reviews what the PowerShell ISE is and why it is beneficial for both beginners and advance users. One of the last sentences contains the missing information I was looking for…" Windows PowerShell ISE is an optional feature." Now, I know why I couldn’t find it!!

So to get the ISE for use, the steps are simple and straight forward.

1. Open Server Manager

2. In the left-hand navigation tree select Features

a. clip_image002

3. Next click Add Features. This will launch the "Add Features Wizard"

a. clip_image004

4. Scroll down until you find Windows PowerShell Integrated Scripting Environment (ISE).

5. Click the check box and then click Next

6. Click Install

7. Now get up and do a few jumping-jacks to keep from getting leg clots, while the progress bar fills…..1…2…3…4…you can do 10, I have confidence in you.

8. Click Close once installation has finished.

9. A search for ISE now gives you two options

a. clip_image006

10. Now we can use the PowerShell ISE for development.

Now we can create scripts in a pretty environment, but what about running them. If you have just written a simple or for that matter complex script to perform some task, let’s say to write the all popular "Hello World!" to the screen. Your script might look like the following:

clip_image008

Now click the little green arrow or click F5. If your system is fresh the following error message most likely came up:

clip_image010

[For the search engine sake the message reads: File cannot be loaded because the execution of scripts is disabled on this system. Please see "get-help about_signing" for more details.]

Well, now this is a problem all we wanted to do was to greet the world from our machine….My understanding is that by default and for good reason PowerShell no matter what level user you are will not run a script that has not been digitally signed. You can run your PowerShell prompt as administrator and you will still get this message. It is a security feature to make sure you understand and know what you are about to run. This is great if you grandmother is about to run a script called ‘CatInTheCeiling.ps1’ because her friend told her it was the cutest thing in the world.

But for you and I, who actually want to accomplish some work on our development machine, this is a big slow down. We don’t want to spend the time trying to digitally sign a small PowerShell script.

The solution is quite simple, only a few steps:

1. Open a PowerShell command prompt or use the bottom window in the ISE.

2. Run this command: Set-ExecutionPolicy Unrestricted

3. Approve the warning

a. clip_image012

[For the search engine: The execution policy helps protect you from scripts that you do not trust.]

4. And you are done.

To reverse this setting use the Default option instead of Unrestricted.

For further details on the Set-ExecutionPolicy cmdlt check out its entry on MSDN at http://technet.microsoft.com/en-us/library/dd347628.aspx.

HowTo Install SQL Server 2008 R2

Here is the first of what I hope to be a regular part of The Code Attic experience,
a how-to article on something nice and geeky. As I continue to work on building
out my new machine I will document each of the steps I take in creating demos and
development environments.

Before you can develop or start showing demoes data a place to store and keep data
is needed. So after getting the OS up and running (Windows Server 2008 R2 of course)
you need a database. The following are the most straightforward 45 steps I used
to installing SQL Server 2008 R2 Developer addition with Reporting Services and
Analysis Services.

I won’t fully guarantee the steps will work for your setup but it does in mine,
at the very least is should provide some direction for you in your installation.

As always leave thoughts, questions, and tips in the comments.

Fun and luck I send your way.

Machine:

  • Windows Server 2008 R2 Standard x64 Windows
    Server 2008 R2 x64

  • Roles:
    • Active Directory Domain Services
    • IIS
    • Application Server
  • Running as virtual machine within VMWarePlayer 3.1.0 build-261024

Steps:

  1. Run the System Configuration Checker, resolve any issues that it detects
  2. Click Installation
  3. Click New Installation or add feature to an existing installation
  4. Enter Product key
  5. Accept license agreement
  6. Setup Support Rule
    • Windows Firewall Warning to resolve
      • The link which you are redirected to is : Configuring the Windows Firewall to All
        SQL Server Access (
        http://msdn.microsoft.com/en-us/library/cc646023(SQL.100).aspx
        )
        1. Assuming that if you are installing SQL Server you have an understanding of the
          purpose of a firewall I will not summarize the opening paragraphs.
        2. In case you were not aware, a default installation of Windows Server 2008 has the
          firewall on by default.
        3. You finally make it to useable information regarding the above error window about
          a third of the way down the article. The section is called “Ports Use By SQL Server.”
          They are kind enough to provide a table that explains each of the ports and there
          use.
        4. Default instances of SQL Server need TCP Port 1433 opened up. If you will have multiple
          named instances running on the machine additional port planning will need to take
          place, and is beyond the scope of this tutorial.
          • TCP port 1434
            • will need to be allowed if you plan to use Dedicated Admin Connections.
            • This feature is not enabled by default and so will not be covered in this tutorial
              as we are looking to build a basic machine with SQL Server 2008.
          • UDP port 1434
            • listens for any SQL Server Browser requests and provides the needed redirect to
              the appropriate TCP port for the named instance.
          • TCP port 443
            • is the default HTTPS port for SQL Server.
        5. Since we will also be installing Analysis Services the are additional ports to consider
          opening in the firewall will be
          • TCP port 2383
            • Standard port for a default Analysis Services installation
          • TCP Port 2382
            • Used only if a named instances of Analysis Services is being used.
          • TCP Port 80
            • If going to use Analysis Services via IIS (i.e. a connection is allowed to be established
              via a URL)
            • PivotTable requires HTTP or HTTPS
          • TCP Port 443
            • If planning to connect via HTTPS
        6. The final SQL piece our base image will have is Reporting Services
          • TCP Port 80
            • Allows for a HTTP (url) connection to be established
            • It is not recommended to use the default World Wide Web Services rule.
          • TCP Port 443
            • Allows for a HTTPS (secure url) connection to be established.
            • Again it is recommended not to use the default Secure World Wide Web Services rule.
        7. Open up the Windows Firewall and enable the abovementioned ports that relate to
          what you plan to install.
  7. You will be asked to enter your product key code, once entered click Next
  8. The Next step is to accept the Microsoft EULA. Feel free to take time to read it,
    I am sure there is many important things listed. Once you have read to your hearts
    content check the ‘I Accept..’ box, and if you wish to help out with the next version
    check the ‘Send feature usage…’ box.
  9. Click Next
  10. For this base image install SQL Server Feature Installation
  11. Click Next
  12. Feature Selection
    • Select the following
    • This feature set will require approximately 5752 MB
  13. Click Next
  14. The Installation Rules will run. There is a total of 24 rules it checks for. My
    system passed 6 of the rules while the remaining 18 were skipped (given a status
    of ‘Not Applicable’)
    • You will need to resolve any Fails before continuing. It is recommended that you
      correct warnings also.
  15. Click Next
  16. Instance Configuration screen
    • You will now be asked to either accept the default name instance or define a specific
      name for the SQL instance.
    • Since we are building out a fairly default machine for development purposes, select
      ‘Default Instance’
  17. Upon clicking Next you will be asked to review the disk space requirements
    for all the features you selected. If the listed drive does not provide enough space,
    then click Back and change the root directory under Instance Configuration.
  18. You will now be on the Server Configuration screen, where you will be required to
    enter the account which will run each service.
  19. Click Next
  20. The next step is the Database Engine Configuration. This step involves setting up
    the authentication mode and the SA account of the instance of SQL Server.
    • Authentication mode select Windows
    • Click Add Current User if you are currently logged in as an account you want to
      have SA privileges
  21. Click Next
  22. Analysis Services Configuration is the next step. This step is used to setup the
    administrators for Analysis Services.
    • Add all the users you wish to define with such a role.
    • Click Add Current User if the currently logged in user should be granted such permissions.
  23. Click Next
  24. Report Services Configuration is the last of the service configuration steps.
    • Select the top option “Install the native mode default configuration”
  25. Click Next
  26. If you would like to supply error reports to Microsoft check the box.
  27. Click Next
  28. Installation Configuration Rules will run. There is a total of 8 rules which will
    be checked.
    • My system resulted in 6 passed rules and 2 listed as Not Applicable
      • The NA rules are: Instance Name and SQL Server 2000 Analysis Services (64-bit) install
        action
  29. Upon clicking Next you will be given a summary of all the options
    and configurations settings chosen in the earlier steps.
  30. Click Install
  31. Everything has installed now it is time to perform some testing.
  32. The quick an dirty is to open up SQL Management Studio and create a database, if
    it creates you are in luck, it works.
  33. For Reporting Services, there are some additional steps.
  34. Try going to the report services link: http://<your
    server name>/Reports.
    • It will normally ask for credentials, at which time enter some credentials.
    • Most likely you will receive the following error message:
      • “SQL Server Reporting Services Error User <domain>\<name> does not have
        required permissions. Verify that sufficient permissions have been granted and Windows
        User Account Control (UAC) restrictions have been addressed.”
    • As you can guess, the user account must be given some permissions to get in.
  35. So you may be wondering how do I get around this issue and what caused it. My understanding
    is how Reporting Services handles the user accounts that are added during installation,
    see step 22.
  36. Even though you may already be logged in as the administrator for the system and
    SQL, you must run Internet Explorer as Administrator
  37. Re-enter the url for Report Server Manager (http://localhost/Reports)
    and you will be see the following
  38. Click Site Settings in the upper right hand corner. You are now
    in the site settings section of Report Server (if you are familiar with Windows
    SharePoint Server 3.0 you will notice some similarities in the setup of the screen.
    (Always nice of them to reuse good ideas.)
  39. On the left hand side click Security
  40. Click New Role Assignment this will take you to the page were new
    users can be added with different level of security (admin or user)
    • Here is a summary of the roles available, paraphrased from ‘User Predefined Role’
      at http://msdn.microsoft.com/en-us/library/ms157363.aspx.
    • Role Description
      System Administrator A user has the ability to enable features and set defaults throughout the system.
      In addition, has the ability to set site-wide security, and define role definitions,
      along with manage all jobs.
      System User Only basic server information is viewable to this role group.
    • You need to add at least one user as a System Administrator so that you no longer
      have to run as administrator. For my set-up I will be adding both a system user
      and a system administrator user. This will allow me to have separation of control
      during demoes. I would recommend creating two new user groups on the machine which
      are assigned the appropriate role levels, and then adding the accounts to the groups.
      This will allow you to quickly make changes as new test accounts are created and
      used, along with getting you in the practice of thinking about security in terms
      of groups and not individuals.
    • In addition to setting the system roles you must setup roles for the actual folder/viewing
      level also. To do this return to Home, and click Folder Settings.
      • You will see a similar security setting page as before. Click New Role Assignment
    • As with before either groups or users can be assigned the different roles. Depending
      on you planned strategy it may make since to assign individual users at this level,
      but remember the more individuals you begin assigning, the more difficult administration
      tasks can become.
    • Here is a summary of the roles available, paraphrased from ‘User Predefined Role’
      at http://msdn.microsoft.com/en-us/library/ms157363.aspx.
      • Role Description
        Content Manager All item level roles are wrapped into this single role. This means users or groups
        assigned the role are able to grant permissions, define folder structure, and all
        other management abilities of report server content.
        Publisher Grants the ability to add new items to the report server, including new reports
        and folders
        Browser Can run, subscribe, and browse reports. Can be considered a read only permission
        level.
        Report Builder Has the ability to author and edit reports which exist in the Report Builder
        My Reports Allows user to create a personal report workspace (think a SharePoint MySite like
        experience) were they can store and manager reports for personal use.
      • My recommendation is the user assigned the System Administration role at the site
        level should also be granted Content Manager role at this level. While your system
        user level group/user should be given at minimum Browser role, if not more. This
        is your call as to how you plan on using the system.