Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • Topic author was deleted

    Jun 20, 2014 @ 16:26

    Client Dependencies not being created following server move and domain change

    I'm experiencing two issues shortly after moving to a new server and changing my site's bindings in IIS.I moved the site to the new server on Tuesday, and everything was working fine until I finally changed the bindings from its dev domain name to the live domain last night.

     

    The first issue, is that when attempting to access the backend, I get an error indicating that Umbraco can't resolve the Client Dependency file mappings:

     

    "Could not parse the URL path:  with the format specified: {dependencyId}/{version}/{type}"

     

    I've tried deleting the ClientDependency folder to see that everything's being created properly.  However, on accessing the site, a new ClientDependency folder is created, along with an empty map file.  No other files are created.  I think this indicates a permission issue, but my App Pool user has full control over App_Data.

     

    Switching to debug="true" works.  The front end site works perfectly well whether debug is true/false, it's just the backend that I'm having trouble with.

     

    The second issue, is that when switching debug="true", I now get a "login failed for user" on attemping to access admin.  My password is definitely correct, but I'm wondering is this is related to the above?  I've tried setting it to "Clear" but still can't login.

    Does anyone have any pointers for where I should be looking to sort this?

     

    EDIT: Weirdly, I tried this by binding port 80 * to the site, and I can reach the login page using "IP/umbraco/".  Could it be because my domain name has a "-" in it?  Is Umbraco that sensitive?

  • Jan Skovgaard 11280 posts 23678 karma points MVP 10x admin c-trib
    Jun 21, 2014 @ 17:38
    Jan Skovgaard
    100

    Hi There

    According to your "Edit" comment does it mean your issue has been solved? Or are you still struggling?

    I don't think that the "-" in the domain should be an issue.

    What exact version of Umbraco 7 are you using?

    Deleting the client dependency temp file is a good thing - You also need to go to the /config/ClientDependency.config and increment the version number and then recycle the app pool in order for the changes to take effect.

    You mention the the app pool user has sufficient permissions (usually it's run by network service) - But the rule of thumb is that network service and the iusr accounts should have full permissions - Alternatively you could set it to the iis_iusrs group.

    As an experiment you could try and provide full access to the everyone role if it's not too risky.

    Hope some of these pointers help.

    /Jan

  • Comment author was deleted

    Jun 23, 2014 @ 23:42

    Hi Jan, thanks for taking the time to post.  My domain name edit was made after staring at it for several hours and going in circles!  :-)

    I took a copy of the site, and placed it on a different server -> worked fine.  I then created a new copy of the site on the original server, created a new site in IIS, and applied the relevant IIS_IUSRS permissions on the new directory.  I also commented out the rules that I had applied through the UrlRewrite component in IIS.  I was using this to assist with some 301 redirects from the old version of the site.

    These two steps seemed to solve the issue.

    Un-commenting the UrlRewrite rules in the web.config seems to cause the problem to return.  I've still to do some follow up, trying each rule one at a time to nail it down exactly, but I believe that what I was experiencing was a combination of problems caused by some of my UrlRewrite rules, and some incorrect Windows permissions on the Umbraco directory, as you suggested.

    Thanks for the pointers!

  • Nathan Skidmore 63 posts 251 karma points c-trib
    Aug 03, 2015 @ 11:26
    Nathan Skidmore
    0

    I just had the same problem and for me it was caused by a redirect rule.

    The pattern had a double backslash to escape a single slash. Once I removed the double and just left the single it worked fine. Reading up more on Regex you should escape the forward slash with a double, but you don't need to do this for a backslash.

Please Sign in or register to post replies

Write your reply to:

Draft