We recently added a second website to a client’s EPiServer installation, and wanted to use the existing ImageVault installation here as well. We hit a few snags, but nothing really difficult to handle.
ImageVault licenses and publishing sources
While EPiServer counts the number of sites in an EPiServer installation for their licenses, ImageVault does a similar thing; they keep track of how many different publishing channels (or publishing sources) you’ve got. A publishing source is for instance an EPiServer website, but may also be other distribution channels that make use of the content you’ve got stored in the system.
While the EPiServer license we used allowed for up to five EPiServer websites, we needed a similar one for the ImageVault installation. A five publishing sources license was ordered and added to our solution.
A thing to keep in mind here is that if you go around changing hosts for your EPiServer site, ImageVault will either say that you cannot add another publishing source, or the ImageVault database table keeping track of the publishing channels will fill up. So if you for instance would move your local ImageVault database to a system test environment to allow webeditors to work with it, and then continue to move it into your production environment, you may end up with three publishing sources registered; your local URL, the system test URL, and the production URL. ImageVault describes the way of Changing the name/binding of your site on their support pages.
The database table holding the publishing sources is called PublishingSources, and the reason that you’re not recommended to go around adding or removing entries here is as far as I can see, that you’ve got a PublishingSourceId acting foreign key in the PublishedMediaContentReferences table (which in turn keeps track of which channels published what media and so forth).
MediaProxyHandler WebException while accessing ImageVault – The remote name could not be resolved
This exception occured once we got the second website set up on one of our editor servers. The website and EPiServer’s edit mode was content with us accessing the new edit mode url cms.the-new-site.se once it was set up in the admin mode, and bindings was added to the IIS. However, trying to use the ImageVault Gadget, or accessing the ImageVault interface caused problems.
When you use ImageVault, it needs to ask the EPiServer installation for your user’s level of access. Since the ImageVault UI is in fact a virtual application underneath your EPiServer website in the IIS, it needs a way to contact the CMS. The way that it’s done is by sending a request to the only URL it knows; cms.the-new-site.se. For us, the ImageVault UI on the editor machine could not resolve the DNS and didn’t know where to go. So to keep the call locally on the editor server, we added a mapping in the hosts file (C:\Windows\System32\drivers\etc\hosts) pointing cms.the-new-site.se to 127.0.0.1.
The below exception was written to your ImageVault UI logs on the editor machine.
[ImageVault.Client.Web.MediaProxyHandler] ImageVault.Common.Lib.Web.HttpHandlerBase.System .Web.IHttpHandler.ProcessRequest - Error processing request for http://cms.the-new-site.se/imagevault/media/ghptdcauzaaap8m1xuxa/some-image.jpg System.Net.WebException: The remote name could not be resolved: 'cms.the-new-site.se' at System.Net.HttpWebRequest.GetRequestStream(TransportContext& context) at System.Net.HttpWebRequest.GetRequestStream() at ImageVault.UI.Mvc.Security.IdentityLookupServiceClient.Call[T](String name, Object argument) at System.Web.Security.RolePrincipal.GetRoles() at System.Web.Security.Roles.GetRolesForUser(String username) at ImageVault.Common.Security.DefaultClientSecurityManager .GetRoleIdentityList(IPrincipal principal) at ImageVault.Common.Security.DefaultClientSecurityManager.<GetRoleIdentities>d__0.MoveNext() at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection) at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source) at ImageVault.Client.ClientFactory.GetCurrentUserClient()
