InfoPath Dev

 If anyone has been following this, I actually came across a much easier solution than changing either the form's security, or the server's security.  I republished the form to reflect the proper URI with no redirection.  There was much cache cleaning and teeth gnashing in between, but I now have a form that will ...

Well, it looks like I found out what happens when you try to use a redirected URI to find the form's XSN... You get a message stating: "This form cannot be opened because it requires the domain permission level and it currently has restricted permission. To fix this problem, open the form from the location it was published ...

Hi Clay - Thanks for the welcome. The way we implement the redirect will depend on what works best for InfoPath.  We would like to take the simplest path from point A to point B, but we do have some flexibility in explaining our application-based requirement to our network powers-that-be, and asking them to implement in a specific manner so ...

Hi - I'm working on a project where we serve up our XSN to our users via the URL in the InfoPath PI.  The URL goes to an actual internet domain, and we are not using Sharepoint in this workflow in any way. My employer has just change the company name, and plans to retire the server where our XSN file is currently located.  However, ...

Hey Shiraz - We want to move our XSN file from one server to another server - but the question remains, what to do with the existing forms that were pointing at server A.  I know that anyone who has previously opened a form on server A will have a cache of the XSN on their computer, so they'll still be able to open the form if InfoPath ...