What Every SharePoint Admin Needs to Know About Host Named Site Collections

  • Article

This post intends to tell you everything you need to know about host named site collections so that you can decide if they are appropriate for your environment.  This post is NOT telling you to run out and create everything as host named site collections in SharePoint, instead it is meant to help educate you about a feature that exists as part of the product.  Simply put, I heard from some of my customers that there was some misinformation in the community saying to never use host named site collections.  This is plain wrong, just as saying to always use them is also wrong.  This post explains what host named site collections are, how to use them, and some limitations to consider if you intend to use them. 

What Are Host Named Site Collections

A host-named site collection allows you to address a site collection with a unique DNS name, such as “https://fabrikam.com”. 

Typically you will create a SharePoint web application, and it contains many path-based site collections that share the same host name (DNS name).  For example, Team A has a site collection at https://contoso.com/sites/teamA, and Team B has a site collection at https://contoso.com/sites/teamB.  These are referred to as path-based site collections, and is the recommendation for most corporate scenarios.  Host named site collections enable you to assign a unique DNS name to site collections.  For example, you can address them as https://TeamA.contoso.com and https://TeamB.contoso.com, which enables hosters to scale to many customers.

SharePoint makes the decision on how to map the host name to the site collection when the SPSite object is constructed.  It internally uses the SPWebApplication object to find the web application in the configuration database and determine if there is a host header associated with the site collection.  If no host header information is returned, this is a typical site collection.  Turn on Verbose logging, and for path-based sites you will see a ULS entry similar to “Looking up the additional information about the typical site https://contoso.com/sites/teamB”.  If host header information is returned, then the host named site collection information is retrieved.  You can see this in the ULS log with the entry “Site lookup found the host header site https://hosta.sharepoint.com/Pages/default.aspx”.

Host named site collections have been in the product since SharePoint 2003, where it was referred to as “scalable hosting mode”.  The point is that host named site collections is not a new feature to SharePoint 2010, it has been around a long time and customers have been successfully using it in their environments for many scenarios for quite a long time now.

Admittedly, there were several known issues with the implementation early on in SharePoint 2007, such as the inability to use blobcache with host name site collections (see Stefan Gossner on MOSS 2007 blob caching and its limitations), which has contributed to the misinformation in the community and lingering perception issues about the appropriate use of host named site collections.  This issue as well as several others were addressed early on with SharePoint 2007.  You can see in the screen shot below that images are in fact cached using blobcache using SharePoint 2007 just fine.

image

To be clear, the blobcache issue was never an issue in SharePoint 2010, in fact SharePoint 2010 made two significant improvements for host named site collections: the ability to use managed paths with host-named site collections, and the ability to use off-box SSL termination with host-named site collections.  Host-named site collections can also be used to implement multi tenancy solutions (for a complete discussion on multi tenancy in SharePoint 2010, see Spence Harbar’s excellent Rational Guide to Multi Tenancy in SharePoint 2010).  Office365 is implemented using host named site collections and multi tenancy as this is how the product scales to support many, many customers for that specific hosting scenario.

Creating Host Named Site Collections

To better understand host named site collections, let’s see how you create them. You cannot use the self-service site creation web UI to create a host-named site collection, but instead you use PowerShell. The following code creates a new web application listing on port 80, and two host named site collections that use the Publishing Portal site template.

 $w = New-SPWebApplication -DatabaseName "WSS_Content_HostNameTest" 
    -ApplicationPool "SharePoint - Content App Pool" -Name "HostNameTest" -Port 80 

#Remember to do IISRESET /noforce on each server before using the new web application 

$w = Get-SPWebApplication "HostNameTest" 

New-SPSite https://HostA.SharePoint.com -OwnerAlias "SHAREPOINT\kirkevans" 
    -HostHeaderWebApplication $w -Name "HostA" -Template "BLANKINTERNETCONTAINER#0" 

New-SPSite https://HostB.SharePoint.com -OwnerAlias "SHAREPOINT\kirkevans" 
    -HostHeaderWebApplication $w -Name "HostB" -Template "BLANKINTERNETCONTAINER#0"

The result is a web application that contains my two host-named site collections.  There is a third site collection for the Office Viewing Cache because I am using Office Web Apps.  I did this to show that you can have a mix of path-based and host named site collections within the same web application.

image

We created two host named site collections, but I didn’t say anything about adding the host headers into the IIS bindings. That is because the web application that contains them listens to *:80, any port 80 traffic that is not otherwise directed to another web application on the same machine is directed to this web application.  You can verify this by looking at the bindings for the containing web application in IIS.

image

This is an important point to consider.  If you create the web application with a non-default port, something like 3759, your host named site collections should also be on that port.  Otherwise, you will have to manually add the host header entries in the bindings in IIS, and do this on every machine.  Just say no to non-default ports, use port 80 and make everyone’s life easier.  You really do not want to start editing the bindings for the web applications manually, especially on every machine in your farm.  Typically you will just use a web application that listens on *:80.

Reiterating this point, if you are going to implement host named site collections, you should not use a host header for the containing web application that houses the host named site collections or it will not work properly.  Doing so will create a host name binding for the web application in IIS, and the other host names will not be routed to the IIS site.  In the example I used, all host names are processed by port 80, which alleviates the need to manually add host bindings in IIS.  This has one unfortunate downside: if other web applications that use host headers, say contoso.com:80, are stopped due to application pool failures or other issues, then the application that listens on *:80 will process the traffic.  This can lead to unexpected results if the contoso.com:80 site uses a different authentication mechanism or is processed by a different application pool identity.  It’s just a function of how IIS works, but something to consider when designing your applications and something you should test in your environment (you do test things before implementing them in production, don’t you?)

Managed Paths and Host Named Site Collections

As stated previously, an improvement to host named site collections in SharePoint 2010 is the ability to use managed paths.  As we saw when creating host named site collections, there is no UI to create a host header managed path, you instead use PowerShell using the –HostHeader switch on the New-SPManagedPath PowerShell command.

 New-SPManagedPath "cthub" -HostHeader -Explicit

$w = Get-SPWebApplication "HostNameTest"

New-SPSite https://HostA.SharePoint.com/cthub -OwnerAlias "SHAREPOINT\kirkevans" 
     -HostHeaderWebApplication $w -Name "HostA Content Type Hub" -Template "sts#0"

In this example, we create a managed path “cthub” and create a site collection using that managed path.  The results are as you would expect, a new site collection is created using the HostA.SharePoint.com DNS name using the managed path “cthub”.

image

This can be hugely beneficial when defining consistent provisioning solutions.

Can I Use Alternate Access Mappings with Host Named Site Collections?

SharePoint provides a capability to create a web application using a host name such as https://publishing.contoso.com, and you extend the web application using a new alternate access mapping for the web application to a new host header such as https://www.fabrikam.com. This is particularly useful when you have different users accessing the same content through different authentication means. Internal users authenticated with Windows claims can access the web application using https://publishing.contoso.com, and external users access the same content using https://www.fabrikam.com. The difference is the URL that you use to access the web application.

With host named site collections in SharePoint 2010, you do not have the ability to provide different authentication mechanisms based on the host header. Remember that this happens at the web application level. Using our previous example of a web application “HostNameTest” that contains two host named site collections, “HostA.SharePoint.com” and “HostB.SharePoint.com”, it is not possible in SharePoint 2007 or 2010 to provide different authentication to each of the site collections. This means that you cannot use alternate access mappings with host named site collections. This should be a consideration when designing your information architecture.  If you need to support site collections responding to multiple host-name URLs, consider using path-based site collections with alternate access mappings instead of host-named site collections.

Host Named Site Collections Only Use One Host Name

Continuing on the discussion on AAMs and host named site collections, you cannot use multiple host names to address a site collection in SharePoint 2010. Because host-named site collections have a single URL, they do not support alternate access mappings and are always considered to be in the Default zone.  This is important if you are using a reverse proxy to provide access to external users. Products like Unified Access Gateway 2010 allow external users to authenticate to your gateway and access a site as https://uag.sharepoint.com and forward the call to https://portal.sharepoint.com. Remember that URL rewriting is not permitted. Further, a site collection can only respond to one host name. This means if you are using a reverse proxy, it must forward the calls to the same URL.  If your networking team has a policy against exposing internal URLs externally, you must instead use web applications and extend the web application using an alternate access mapping.

Host Named Site Collections and SSL

We’ve pointed out several times that we can only use one host name, can we simultaneously use both HTTP and SSL based URLs simultaneously?  The answer is no.  By default, host-named site collections in SharePoint 2010 use the same protocol scheme as the public URL of the Default zone of the web application.  If you wish to provide host-named site collections in your Web application over SSL, ensure that the public URL in the Default zone of your Web application is an HTTPS-based URL. 

[Update: thanks, Spence Harbar!]   The August 2010 Cumulative Update adds additional support for both HTTP-based host-named site collections and HTTPS-based host-named site collections to coexist in the same web application. By default this support is disabled. To enable this support, set the

Microsoft.SharePoint.Administration.SPWebService.ContentService.EnableHostHeaderSiteBasedSchemeSelection property to true. As soon as it is enabled, SharePoint will no longer use the web application's default zone public URL protocol scheme for all host-named site collections in that web application. Instead, SharePoint will use the protocol scheme provided during host-named site collection creation, restoration, or rename. Host-named site collections that are created before this update is installed will default to use the HTTP protocol scheme if this property is set to true. These site collections can be switched to use the HTTPS protocol scheme by renaming the host-named site collection and providing an HTTPS-based URL as the new site collection URL.

To configure SSL for host-named site collections, enable SSL when creating the Web application. This will create an IIS Web site with an SSL binding instead of an HTTP binding. After the Web application is created, open IIS Manager and assign a certificate to that SSL binding. You can then create site collections in that Web application.

A server certificate has to be installed and assigned to the IIS Web site. Each host-named site collection in a Web application will share the single server certificate assigned to the IIS Web site.  You need to acquire a wildcard certificate or subject alternate name certificate and then use a host-named site collection URL policy that matches that certificate.  For example, you will need a *.sharepoint.com wildcard certificate to generate host-named site collection URLs such as https://hosta.sharepoint.com, https://hostb.sharepoint.com, and so on, to enable these sites to pass browser SSL validation.  If you require unique second-level domain names for your sites, you have to create multiple Web applications rather than multiple host-named site collections.

Because SharePoint Server 2010 uses the public URL in the Default zone of the Web application to determine whether host-named site collections will be rendered as HTTP or SSL, you can also use host named site collections with off-box SSL termination.  As discussed in the previous section, “Host Named Site Collections Only Use One Host Name”, the SSL terminator must preserve the original HTTP host header from the client.  As discussed in the TechNet paper, Plan for host-named site collections (SharePoint Server 2010), there are 3 requirements to use SSL termination with host-named site collections:

  • The public URL in the Default zone of the Web application must be an HTTPS-based URL.
  • The SSL terminator or reverse proxy must preserve the original HTTP host header from the client.
  • If the client SSL request is sent to the default SSL port (443), then the SSL terminator or reverse proxy must forward the decrypted HTTP request to the front-end Web server on the default HTTP port (80). If the client SSL request is sent to a non-default SSL port, then the SSL terminator or reverse proxy must forward the decrypted HTTP request to the front-end Web server on the same non-default port.

The ability to use SSL termination and managed paths makes host header site collections a very powerful tool for hosting scenarios.

Size Matters

When you need to create vanity URLs, the first question you must ask yourself is “how many URLs will I need?” The unit of scale for SharePoint is at the site collection level. There is a tested limit of around 100 web applications for SharePoint, while each web application can have up to 250,000 site collections (see notes in the section “Know Your Limits” for discussion on number of web applications). When talking about options for vanity URLs, size matters. I have heard several people blanketly denounce host named site collections without providing context around the size of the environment or the solution being architected. It is important to remember the guidance in the SharePoint Server 2010 capacity management: Software boundaries and limits paper when architecting your information architecture. If you require a handful of vanity URLs, you are likely going to be better served creating web applications and leveraging alternate access mappings. If you are creating hundreds or thousands, then obviously you can’t create this many web applications, you are left with host-named site collections.  See the section below “Know Your Limits” and understand the software boundaries and limits when designing your information architecture. 

Uptime Matters

When you create a new web application using the SharePoint web UI, you are reminded to use “IISRESET /noforce” on each of the servers before using the web application.  Simply put, this affects your uptime, even for a very short duration.  A benefit to host named site collections is that you do not need to issue IISRESET when you create a site collection, host named or path-based.  Maybe this isn’t a big deal in your environment, but in some environments an IISRESET is a big deal.  You can see in my example above that I include a note reminding you to use IISRESET on each machine, this is only because I created a new web application as part of the demo.

Can’t I Just Rewrite the Path? 

ASP.NET 2.0 introduced a very cool feature that you could rewrite a URL programmatically, such that a request for https://contoso.com/employees/kirk could be rewritten to https://contoso.com/sites/HR/pages/Employees.aspx?Emp=Kirk.  This allows for URLs that are easier for end users to understand and navigate your web site.  SharePoint does not support asymmetrical URL rewriting (https://technet.microsoft.com/en-us/library/cc288609(office.12).aspx).  Modifications to the content path or the host name are not supported.  This means that URL rewrites (different than redirects, see the next section) cannot be used with SharePoint 2010.  I have seen several developers try to do this to do things like remove “Pages” from the URL, this is not supported either.  The inability to rewrite the path has implications on other scenarios, such as reverse proxies.  See the section “Host Named Site Collections Only Use One Host Name” for a discussion on reverse proxies.

What About Redirects?

If your goal is to provide vanity URLs, then there is another approach to consider: using HTTP redirects.  You can configure IIS to redirect all requests to a particular path to another resource.  This is different than URL rewriting because the client makes a request to a resource, receives a 302 redirect response, and then requests the new resource based on the information in the 302 redirect.  In fact, Jie Li mentions using redirects in an attempt to address SEO.  For many cases, this is absolutely a great approach.  However, consider that SOAP (web services) does not handle 302 redirects.  This means anything that calls SharePoint with the vanity URL will not work.  If your end user tries to use one of the Office client applications and work with SharePoint using their vanity URL, they will receive unexpected behavior and error messages because those applications use SOAP to communicate with the server. 

Kerberos and Host Named Site Collections

You are probably wondering if you can use Kerberos with a host named site collection, and the answer is yes.  To prove this, I configured the web application “HostNameTest” to use Negotiate for authentication.  Its application pool is running as an account sharepoint/sp_app.  The DNS entry for “hosta.sharepoint.com” was set up as an A record.  I added a SPN “HTTP/hosta.sharepoint.com” to that account, made a request, and we see a Kerberos ticket when I use KLIST.exe.  This shows that I am getting a Kerberos ticket. 

image

Yes, Kerberos works with host-named site collections.

Migrating Path-Based to Host Named Site Collections

If you have a number of web applications that provide vanity URLs and you are approaching some of the software boundaries for too many web applications (see the next section!), you are probably wondering if you can somehow collapse the information architecture to use host named site collections instead of path-based site collections in web applications.  The answer is yes!

In order to convert from path-based to host named site collections, you have to use backup and restore using PowerShell.  Back up the site collection to a file using Backup-SPSite, and then restore to a host named site collection using Restore-SPSite.

 Backup-SPSite https://server_name/sites/site_name -Path C:\Backup\site_name.bak

Remove-SPSite –Identity https://server_name/sites/site_name –Confirm:$False  

Restore-SPSite https://www.example.com -Path C:\Backup\site_name.bak -HostHeaderWebApplication https://server_name

It goes without saying that when you backup and restore, make sure that you are not creating multiple site collections that are identical in your farm to avoid duplicate GUIDs.  It is important that you remember to use Remove-SPSite before Restore-SPSite in this example.

In SharePoint 2007, site collection restore was performed with “stsadm –o restore”, which did not provide a mechanism to specify which content database would contain the site collection.  A nice change in SharePoint 2010 is the Restore-SPSite command allows you to specify the content database that will house the site collection.  This lets you kill two birds with one stone if your old path-based site collection was contained in a content database that was approaching the 200 GB limit, you can move the content to a new content database.

By default, the site collection will be set to read-only for the duration of the backup to reduce the potential for user activity during the backup operation to corrupt the backup.  Another nice feature of the improved capabilities in SharePoint 2010 (compared to SharePoint 2007) is the ability to use SQL snapshots with SQL Server Enterprise Edition.  If you have SQL Server Enterprise Edition, we recommend that UseSqlSnapshot parameter be used because this ensures a valid backup while it allows users to continue reading and writing to the site collection during the backup.

See the next section, “Know Your Limits”, for discussion on limitations of the Backup-SPSite and Restore-SPSite commands.

Know Your Limits

There are many factors that you should consider when designing any information architecture, host-named site collections or not.  As a SharePoint administrator, you should commit the SharePoint Server 2010 capacity management: Software boundaries and limits paper to memory.  I am pointing these limits because while most readers will have small farms with a handful of cases where host named site collections are used, there are a few administrators of huge farms that could potentially have tens of thousands of host named site collections.  Understand the limits of the product when designing your provisioning solution.  Also understand that some of these limits are extreme boundaries that may not be at all applicable to your environment, in fact your environment may not be capable of reaching some of these numbers. 

  1. The number of application pools is limited to 10 per web server.
  2. There is no published limit for the number of web applications for SharePoint 2010.  The limit in SharePoint 2007 was 100 web applications total.  Most of the Premier Field Engineers that I work with recommend that this limit generally applies to most SharePoint 2010 environments.  This is due to the number of timer jobs, resource contention, and other factors that vary by environment.  In fact, most PFEs recommend a practical limit of number of web applications to around 20 web applications to improve manageability of the environment.
  3. Each web application can have up to 300 content databases. 
  4. Each content database can have up to 200 GB of content. 
  5. Maximum recommended 2000 site collections per content database. If you intend on creating many site collections, take this and the max content database size in mind. 

Other considerations to keep in mind is how your information architecture may impact search.  Search will not automatically pick up the host named site collections, you may need to manually add the addresses in as start addresses or as content sources. Given the limit of 100 start addresses, you may need to define multiple content sources and start addresses. This means you need to keep the following software boundaries and limits in mind:

  1. Limit to 100 scope rules per scope; 600 total per search service application.
  2. Maximum 200 site scopes and 200 shared scopes per search service application.
  3. Maximum 50 content sources per search service application.
  4. Maximum 100 start addresses per content source.

If you are using host named site collections for vanity URLs (not using multi-tenancy), you should also consider the behavior of the PeoplePicker.  You can adjust the PeoplePicker settings to only resolve names within the current site collection (https://technet.microsoft.com/en-us/library/gg602070.aspx).  This isn’t really anything to do with host named site collections, but worth pointing out.

As mentioned in the Migrating Path-Based to Host Named Site Collections section above, content is migrated from path-based to host-named site collections using Backup-SPSite and Restore-SPSite (replacing the stsadm backup and restore).  This command has a tested limit of 15 GB.  I have one customer who is able to use this command with much larger content databases, and another customer who times out with 18 GB databases.  It varies depending on disk latency for the local disk as well as disk latency / throughput in SQL. Know that the supported limit is 15 GB if you intend to migrate from path-based to host named site collections.

Wrapping Up

Host named site collections are a great tool to keep in mind when designing your information architecture.  However, you must also consider other limitations and decide if host named site collections are appropriate for your scenario and understand the practical limits of the product when designing your information architecture.  And the next time that you hear someone blanketly say “never use host named site collections”, please have them visit this blog post so we can bring them up to date Smile

Many thanks to Spence Harbar, Sean Livingston, and Keith Bendure for reviewing this article!  As always, if you have any feedback to this post, please post comments to this blog post so that others can see.

Comments

  • Anonymous
    March 28, 2012
    Fantastic article!

  • Anonymous
    March 28, 2012
    Wow, absolutely fantastic article Kirk. Thanks for demystifying this. Several times even just beginning to mention host named site collections or multitenancy as an option draws immediate ire, even though it may be a perfectly reasonable (or more ideal) approach.

  • Anonymous
    March 28, 2012
    Definitely a great article.  We use host named site collections a lot in 2007 for multitenancy.  We are building up our 2010 multitenant farms currently and this is definitely a feature not commonly seen.Very useful

  • Anonymous
    March 28, 2012
    How do we get the power while extending? For example . intranet.contonso.com - default - sites.intranet.contonso.com   . I want to extend for external access extranet.contonso.com . How do I get the site collection as sites.extranet.contonso.com?

  • Anonymous
    March 28, 2012
    The comment has been removed

  • Anonymous
    March 29, 2012
    Kirk,Good article. I admit to steering people away from host named site collections. This calms some of my fears.tk

  • Anonymous
    March 29, 2012
    Great post I have never seen on HNSC. Thank you.

  • Anonymous
    April 07, 2012
    Really cool article. Awesome job.

  • Anonymous
    April 12, 2012
    Hi Kirk, congratulation on a great article!I wasnt aware of the possibilites with HNSC.

  • Anonymous
    May 22, 2014
    The comment has been removed

  • Anonymous
    June 12, 2014
    Great article! However, I have one question, we set up HNSC in our production environment and I'm trying to duplicate the same HNSC on a different server. Can I use the same names?

  • Anonymous
    July 10, 2014
    The comment has been removed

  • Anonymous
    August 14, 2014
    Vera - we use hosts files on our servers (and on those PCs that need to access them) on our non-production farms, and we can use the same host names just point them to the "new" IP addresses.

  • Anonymous
    August 24, 2014
    Kirk,How much of this advice applies to SP 2013?Mike B

  • Anonymous
    August 24, 2014
    @Mike - Host Named Site Collections are hugely important in SharePoint 2013.  Our guidance is to use a single web application, and the way that you achieve this is through a mix of path-based and host-named site collections.

  • Anonymous
    October 07, 2014
    Hi Kirk,I have a quistion about features in a SiteCollection in a hnsc.We use both (hnsc and path-based) in a SharePoint 2010 Farm.In a SiteCollection who is running in a hnsc, we need the "ReviewWorkflowsSPD "Feature, but i can't see it in  in the "Site Setting".If i use the powershell "Enable-SPFeature" i get the message "Cannot find an SPSite object with Id or Url".Is there a special trick to enable hidden Feature in a sitecollection in a hnsc?Gerd B

  • Anonymous
    November 17, 2014
    Hi Kirk,There is an issue we are facing with Claims FBA Authentication against multiple HNSC style site collections on a single Web Application. This is to confirm if FBA is a tested authentication mechanism against multiple HNSC site collections on a single Web Application.Thanks

  • Anonymous
    December 29, 2014
    Great Post Kirk. Thanks for sharing.Faisal Masood

  • Anonymous
    January 05, 2015
    Hi Kirk,Is there anything special that needs to be done for cross domain authentication of a user account? With path based I just configured the PeoplePicker, when I try that with this setup I get no results. I confirmed the PeoplePicker configuration is breaking it by removing the setup and then I am able to add a user from the domain my SP servers live on. Any suggestions?

  • Anonymous
    February 15, 2015
    Can we have multiple web applications for different HNSC?I have a requirement in my project to group HNSC's into 2. I have created one web application on port 80 but we need another web application for other HNSC's since customization is different for those HNSC's.Can you guide me on this?HNSC: Host Named SIte Collection

  • Anonymous
    April 12, 2015
    This was an elegantly written article that summarized some very complex material into very simple and understandable terms. Great job!

  • Anonymous
    May 13, 2015
    Wonderful article... You helped me a lot today!!

  • Anonymous
    July 07, 2015
    The comment has been removed

  • Anonymous
    July 09, 2015
    Nice!! Have found that when quoates are set up in script it  seems like site.Quota.UserCodeWarningLevel  cant be Zero . This lead to all Host named site Collections not receiving emails , something like this fixed it.            If( -not $site.Quota.UserCodeWarningLevel )            {             Echo "--"             $site.Quota.UserCodeWarningLevel= 100                 $site.Quota.UserCodeMaximumLevel= 300             $site.update            }           Lesson learned : Its easy to script, but the standard prosess gets a lot of standard values filledin correctly as well. So... like HNSC ?  Well , No..

  • Anonymous
    July 23, 2015
    Very nice article. It helped me clear a number of questions.

  • Anonymous
    September 22, 2015
    Kirk, How to implement load balancing with host name site collections?

  • Anonymous
    April 11, 2016
    Hello, Microsoft.SharePoint.Administration.SPWebService.ContentService.EnableHostHeaderSiteBasedSchemeSelection is no longer supported (per the error I received in PS). PowerShell tells me to use RequestRoutingMode instead. I'm looking to use the protocol scheme of my HNSC (https) which differs from that of the web application (http). Do you know of any good resources to explain how to use RequestRoutingMode to implement what you describe previously done by enabling host header site based scheme selection?

  • Anonymous
    June 10, 2016
    Hi,I was wondering if you'd like a free code to check out my brand new Celebrity Voice Changer app? It is totally new technology that blows away all other voice changers in that it actually changes your voice - not just a cheesy effect.If you're interested in learning more, just let me know if you want an iOS or Android code. There is a free version, but it's limited to 5 uses per hour, and I'd really want you to check out more than five celebrity voices including: Hillary and Bill Clinton, Walter White, Kim Kardashian, Oprah, etcI'd love to get your opinion on the app and the tech!-Terry