How to move a ClickOnce deployment

One of the questions I see in the MSDN ClickOnce Forum is how to move a ClickOnce deployment to a different location. You might want to move your deployment because your company is setting up a new webserver, or because you change hosting companies for your deployment.

You can’t just change the URL because it’s part of the security built in to ClickOnce. It checks the update location for the installed application against the URL for the update, and if they don’t match, it won’t install the new version. This keeps someone from hijacking your deployment and substituting their own files.

This video will show you how to move your deployment to a different URL.

This download contains the source code (VS2008, C#) for the three versions of the application used in the video. If you are a VB developer and can’t figure out how to translate the code to VB, please post a comment and I’ll post a VB version of the code.

 Click here to get the source code.

(edit) I couldn’t see how this could work with an Office Solution (VSTO), so I did some looking around. VSTO doesn’t use the update URL at all, so it looks like your customers have to uninstall and reinstall if you have to move a VSTO deployment. Dang.


85 Responses to “How to move a ClickOnce deployment”

  1. Tad Says:

    Very useful video Robin. Thank you for taking the time to document this!

  2. Vaxman2 Says:

    Thanks for the explanation – You made it look easy!

  3. J Davis Says:

    But…. What if you are no longer able to update server 1? Then your users are forced to uninstall / re-install? I’d like an option in the manifest that allows installation of updates from a different server. What about users who access a server by different names depending on if they are in the office or over a vpn? In all these situations, what if this is a “product” and not for internal development? I can’t change the manifest in these situations!

    • robindotnet Says:

      If you can no longer update server1, then you do, indeed, have to have your users uninstall and reinstall. The deal is that the location of the deployment is part of the application identity, and is checked for security when checking for updates. This makes sure someone can’t hijack your user’s deployment and send him to another location to install files that are malicious.

      I’m not sure what you mean by an option in the manifest allowing installation of updates from a different server. You can specify a URL for the updates in the Updates dialog in Visual Studio. That is part of how you move a deployment.

      If you are deploying from a webserver, one thing you can do is use a DNS entry instead of the server address. For example, instead of, use where this is a DNS entry pointing to the same IP address as

      If you could specify multiple update locations, how would the ClickOnce engine decide which one to get the update from? Just keep trying each one until it finds one it can actually use? This would increase the amount of time it takes to pull updates, unless the first address in the list was available.

  4. Karsten Januszewski Says:

    Thanks! Just what I was looking for…

  5. Brian Duper Says:


  6. Dennis Wetherall Says:


    Thank you! This was a great explanation. Unfortunately, my new deployment server is a fileshare ////, rather than a webserver (http://). That means my users need to uninstall and reinstall. Right? I am developing on VS2010.

    Old server: //aaaa/xyz
    New server: //bbbb/xyz

  7. Wesley Says:

    Should this still Work in VS 2010 targetting 3.5? The steps seem straight forward, and I believe I have followed them carefully, but I am getting the following error which seems to explicitly state I cannot change the update location:

    You cannot start application from location it is already installed from location . You can start it from location or you can uninstall it and reinstall it from location . If you reinstall the application, be aware that you might lose any customizations that you made to the application.

    It looks like either MS plugged this helpful hole, or I am doing something wrong. Anyone else experience this problem?

  8. Pedro A. Peña Sanz Says:

    Thanks for the helpful video ant article. But in your example the machine where de deployments “live” is the same. In my case, we need to move from one machine to another and the ip’s and URL’s are completely diffrent. Also both machines are Apache servers.
    When I publish to each of this servers independently, each works fine, updating versions ok.
    But when I set the environment to move from server to the other (deploying that “bridge” version with the update URL pointing to the new server), I get an error related to the permissions. It is something like:
    Subsets of RegEx are not permitted, unless both sets are identical.
    I don’t have any idea what is happening. Is it a problem between servers or is it something related to the way the ClickOnce engine process the file xxx.appref-ms|
    Thanks in advance for any idea.

    • robindotnet Says:

      The example should work for moving from one server to another. I used it for my company to move our deployment from one CDN to another, with totally different URLs.

      Be sure you set up the ClickOnce MIME types on the second server. This article lists them, and discusses apache specifically.

      I’ve never seen that error before – “Subsets of RegEx are not permitted, unless both sets are identical.” When are you seeing this error? Is it when it’s trying to install it, or is it after it has finished installing it?

    • robindotnet Says:

      I think this is a server issue; I’ve never seen that kind of error in ClickOnce. If you’re still having a problem e-mail me, and I’ll ask the ClickOnce lead at Microsoft for his opinion.

  9. Pedro A. Peña Sanz Says:

    Hi Robin. Thanks a lot for your quick reply. I’m not sure if I have to answer by mail or reply in the blog. Anyway, I’ll send you this mail and feel free to put it in the blog or let me know how to proceed.
    First of all, you’re right. I’ve tested each server indepently and the deployments works fine in each one; so the problem about MIME types is discarded (at less at first instance).
    I’ll try to explain step by step what I am doing and what I get.
    1.- Publish version 1.1 in server1 (update URL is empty) and required version=1.1
    2.- Install that version from there and test it works fine.
    3.- Deploy version 1.3 at server2 (update URL is empty) and required version=1.3
    4.- Deploy version 1.2 at server1 (update URL is pointing to server2) and required version=1.2
    5.- Start application at client machine. It checks for updates and it finds version 1.2 at server1, but at this point it finds out that the update URL for this version is at server2 and I suppose it try to download the version 1.3 from server2. It is at this point where I get the error at client machine, not being able to update.

    Thanks a lot in advance for your interest and cooperation.

    PD: I’ve sent you an email with log details.

    • robindotnet Says:

      I don’t know what to tell you; I’m pretty sure our CDN is unix-based, and this worked great for us. Why don’t you try setting the updateURL in version 1.3 to the same as the installation URL, just in case it’s looking at it? The other thing I would verify is that absolutely nothing else changed. If you changed the assembly name or the target CPU or something that is part of the deployment identity, this wouldn’t work. The ONLY thing you can change is the URLs.

  10. Pedro A. Peña Sanz Says:

    Hi again. I reviewed the configuration of Apache (not really me, but the people that manages it) and the problem persist. I don’t really have any idea of what is happening here.
    I’ll appreciate a lot any suggestion.

    Thanks in advance.
    PD: Did you receive the mail with the details?

  11. Mauricio Leyzaola Says:

    Very well explained indeed. Thanks a lot!

  12. Daniel W. Says:

    love it, it saved my bacon. Thank you.

  13. Nick Stringer Says:

    Great video – thanks! However, I have an issue…

    I’m planning to move a couple of applications from the network share where they currently exist to our PDM system, in order to make them accessible to other departments. However, the PDM software we use (SolidWorks EPDM) works by creating a local view of the file archive on the user’s C:\ drive, and as such I’ll need the update path to be what looks like a local one.

    Do you have any idea how I can get around this? From an organisational point of view, it makes most sense to try and push forwards with this approach somehow, rather than using a different network share. The only thing I’ve been able to come up with is using a symlink from the network path where the updates reside to this local path (which should be common to all users), but this seems like a messy solution…

    • robindotnet Says:

      I’m not sure I understand what the PDM software does. You say it “creates a local view of the file archive on the user’s c:\ drive” — create the local view where? Can you install software on the computer from a network share, or that IS the network share? Is it a mapped drive? Can you use a webserver? (You could put them in Azure blob storage for pretty minimal cost, for example).

      If you need a local path as the installation folder, then set the installation URL to some path like C:\ClickOnce\ and copy the deployment over there, and then install it from there. Remember that the installation path must match the location of the deployment and also where the user will pick up updates.

      • Nick Stringer (@Nickedynick) Says:

        We’re using SolidWorks EPDM – it houses all our documents and CAD models on a server, and each PC with client software installed gets a folder on their C: drive which represents the working structure of said server. It’s integrated into Windows so that as far as the user (and PC) is concerned, every file on the server is actually in that folder. The software just stores a cached version of a file in this folder as and when it’s called for so that the entire server doesn’t need to be copied.

        I want to use this system to allow multiple sites access to my programs, since we don’t have any common regular network shares available to all groups.

        The problem I’ve had is that it seems that ClickOnce won’t let you specify a local path as a publishing location, so I’m unable to distribute through EPDM. I was just wondering if you’ve got any workarounds.

        • robindotnet Says:

          ClickOnce DOES let you specify a local path as the publishing file location. What you should do is have it distribute the deployment. For example, put it in C:\MyClickOnceApp\. If I’m understanding you correctly, then it will replicate that folder on the user’s machines.

          Try this — set the publishing file location to C:\MyClickOnceApp\ and leave the installation URL blank. If that won’t fly, then under Publish Options/Manifests, check “Exclude deployment provider URL.”. This is not a secure thing to do, but if you’re only installing in-house, you should be okay. What that does is remove the deployment provider URL, and then when the user clicks on the setup.exe from the C:\MyClickOnceApp\ folder, it sets the install location to that, and looks there for updates.

          Then (in theory), you should be able to put new versions in that directory (with the same file structure as if you published them to a web server), and their app should pick up the updates automatically.

          • Nick Stringer Says:

            Apologies, you’re entirely right! I must have gotten confused – I’m sure there was an issue with local paths not being allowed somewhere…

          • robindotnet Says:

            Nick, it doesn’t let you put a local path in for the installation URL. That’s what you’re thinking of. As noted above, you can get around that, you just have to publish it to the same path you’re going to copy it to on the user’s machine.

      • Nick Stringer Says:

        Sorry, there was a bit of ambiguity in my post. EPDM basically has a server with all versions of important files, and provides users with a “folder” on their C:\ drive which provides a view of the server’s contents, caching the desired versions of requested files. It’s not a mapped drive – just a local view of the archive server which is set up by the client software.

        The reason that I’m wanting to use this is that it’s accessible to all the sites which would require use of my applications (also, I’m primarily a Mechanical Engineer rather than an IT Admin). I could use a webserver, but the one which is available for my use wouldn’t be accessible to one of the sites.

        The problem with this approach is that I don’t believe that it’s possible to publish ClickOnce apps to local drives, since they’re intended for networked use.

  14. Avi Says:

    Hi Robin, (my savior)

    My ClickOnce application suddenly started to fail during launch of the .application via Firefox/Chrome (online /offline application). after many investigation I realized that the tag:
    under doesn’t exist anymore on the manifest and therefore when I try to run it from the “to be installed on” machine it searches for the application manifest on the local system, and obviously can’t find. I edited the manifset using the mage utility and problem solved.
    my question to you is how can I cause VS to rewrite this tag? (I use VS 2010)



    • Avi Says:

      well, here is some partial solution:
      it seems that the element has been removed since I didn’t use the project update feature.
      I perform application updates manually so in order to still get the host name in the manifest I add it’s value to the “update location” field.

  15. Ashish Khatavkar Says:

    very nice.
    i want to add a database file with ext in publish wizard in 2008.
    please help me

    • robindotnet Says:

      I don’t know what “with ext” means. If you want to add a database, you need to add it to the project in Visual Studio. It will then be included in the deployment.

  16. Jason Rohde Says:

    Very usefull information! I do have some questions, though.

    If the developers are deploying to a URL, the sites are migrated to a new server, and then the DNS is changed to point the old URL at the new server, will ClickOnce automatically pick up the updates at the new server?

    • robindotnet Says:

      Yes, ClickOnce will automatically pick up the updates at the new server, as long as the installation URL is the same. It doesn’t care where the URL points to, so you should be okay.

  17. Brian Ushman Says:

    Hi Robin, I have seen so many great responses on here from you, wonderfully done!! I have a specific scenario I am trying to accomplish, can you let me know if this is even possible?

    I have a server app and a client app. I always want the users in an organization to have the client app at the same version of the server (because it’s dependent on the DB schema).

    So if the client has server app 1.0.5 installed. I will need to make sure that the user can still install a clickonce client app from revision 1.0.5 even though the clickonce server could be up to 1.0.7. I thought about the idea of publishing each revision to a seperate URL, however when it comes time to update the client app because a new server app was installed, I am not sure how to proceed. Since the update URL in the project settings was left blank, it will look at the install URL which will only have the current revision. Do you have any suggestions, or any ideas on taking this into a different direction? Hopefully everything I stated was clear.

    Thank you!

    • robindotnet Says:


      I don’t know of any way to do that in ClickOnce, other than for the user to skip the upgrade, which requires him to know what version it is, and what version server app he has. The deployment manifest in the top folder of the deployment folders defines what version the user should be running, and will determine what version the user will get if he installs it brand new.

      And of course if you put every version on a different URL, then the updates won’t work, and the user would have to uninstall and reinstall every time he wants to upgrade.

      Is the problem that the users don’t always have the most updated server application? Can you figure out a way for that app to always be up to date?


      • Brian Ushman Says:

        Thank you for your feedback Robin. You are correct, the server application may not always be up to date in which case I had wanted to allow a user who might have a server a few versions behind to install a matching client which would match that version and not have to upgrade the server each time. But it sounds like I will just have to always force an update on both server and client side. Thank you again for your feedback.

  18. Naama Says:

    Hi Robin,
    Thanks for the useful info! I’ve tried it, but encountered a strange issue, and I was wondering if you’ve seen this before.
    A little background: my application is installed locally, published it to a file share and set to look for updates before the application starts.
    After I publish the updates in both the old and new servers, my application gets the update, and it also copies the user.config, but it doesn’t merge it into the new version.
    BUT, if I restore back to the first version, and then update again (by clicking the .application file in the new location) – the application is updated, including the user.config file.
    This happens when I try two different update scenarios – by closing and reopening the application (to get the update through the application) and when I launch the application from the publish location.

    Have you ever seen this happen?

    Thanks in advance!

    • robindotnet Says:

      I’m not sure what “publish the updates in both the old and new servers” means. Are your customers accessing the deployment from different locations?

      I don’t use the Visual Studio configuration settings feature for storing settings that users can change. Here’s what I know about those settings: When the user installs a new version of the application, if none of the [identity] fields have changed, it copies the old user settings forward to the new deployment folders. If any of the [identity] fields have changed, including the signing certificate, it thinks it is a different deployment and won’t copy the settings forward. The whole thing is a little wonky, if you ask me. So I created my own class that writes a Configuration file in XML and stores it in Application data. This is then updated as the user changes his settings. If the user gets a new version, the file is not overwritten, and I specifically know where the file is and what’s in it. If the user has to uninstall and reinstall the application, he doesn’t lose his settings. This blog entry explains how (and why) I’m doing this.

  19. RT Says:

    Hi Robin,

    Probably a dumb question, but I would need access to the source code right? for COTS products, I’m out of luck with your method? Thanks in advance.


    • robindotnet Says:

      I don’t know what a COTS product is. This article is about moving a smart client deployment that is deployed using ClickOnce. Do you have that, or is it a different case?

      • RT Says:

        Hi Robin,

        Oh yeah, I was referring to a Commercial Off the Shelf product. I don’t have their source code so I can’t open it up in Visual Studio to edit the configurations. I saw some post about using mageui.exe to update the application file but I don’t have their security certificate so I can’t sign them. Any thoughts?


        • robindotnet Says:

          Do you have permission from the company to re-publish their application? Is their application already published with ClickOnce?

          • RT Says:

            Yes, I don’t have their permission explicitly but we are licensed, it is just that we have over 200 users on the app and I don’t really want to go uninstall from every one of those desktop. And yes, the application has already been published with CLickOnce. Thanks in advance for any suggestions.

        • robindotnet Says:

          If your COTS product is a ClickOnce deployment, you probably could take it and move it and re-sign it. You can change the URLs with Mage or MageUI. You *would* have to have your own signing certificate to sign the deployment, though. Not sure if it would work or not, but you could try it.

  20. Marc Says:

    Indeed a great article, but we also have an issue to move a ClickOnce deployment to a new server.
    We copyied the data to the new server and create in DNS the existing url as alias to the new servers ip address. So the url (file share) points to the new server.

    I then started the application on my client, it updated (strange because the new server has the same package) and it resulted in an error:
    Activation of … resulted in exception:
    System.Deployment.Application.DeploymentException (ComponentStore)
    Exception occurred during store operation. Value does not fall within the expected range

    After this we restored the DNS settings and created a new package on new server having the new server url links. To re-install the old server package I had to clear the C:\Users\\AppData\Local\Apps\2.0 folder. I re-installed from old server location and de-installed the application. Then I tried to install it from the new server location. The same error appeared.
    After again clearing the C:\Users\\AppData\Local\Apps\2.0 folder, I successfully installed from the new server location.

    Do you recognize this issue?
    I see the de-install clears some data from this 2.0 folder, but not everything.
    I also tried ‘mage -cc’, but this didn’t help.
    I guess we first should solve the de-install, before retrying the DNS change.
    Can you help?

    • robindotnet Says:

      If all you did was change the DNS entry to point to the new server, has anything about the URL changed at all, even the case? Is it in the exact same folder, etc? I will tell you that “value does not vall within the expected range” usually means a circular reference or you’re referencing two versions of the same assembly. ClickOnce caches common assemblies, so if you have two ClickOnce apps that use the same (strongly signed) assembly, it might have problems uninstalling or reinstalling one of the applications.

      To be honest, I’m surprised you had a problem. We moved one of our deployments by changing the DNS for our domain of our C/O app to point to a new IP address, and had no problem with it.

      • Marc Says:

        Thanks for your reply. I even didn’t expected this problem, because we had the same url and same folder. Maybe indeed something with caching.

        We now implemented the solution you already suggested in your GoldMail:
        1. Clients have installed version from old server
        2. I deployed version on new server
        3. I deployed version on old server having update path to new server
        4. Clients starts again the application and it automatically updates to version (from new server).
        This worked fine.

  21. Vince Says:

    Not sure if you’re still maintaining this blog, but my issue is application on server 1 updated to load application from server 2…like your video. Now I want to update and maintain the click once installs on the server 2. Problem is the application never get the new update…basically want to move the process of click once from server 1 to server 2. Seems to be a dead end.

    • robindotnet Says:

      I’m not sure I understand. If you follow the directions in the article, it should work. The old server has to still be available to pick up the update — is that the case? Did you deploy it as a required update, so the user can’t skip it?

      • Vince Says:

        The directions worked. Now I want to stop publishing to server 1 and start publishing to server 2. When I follow the directions in the article and then publish an update to the new server 2…it doesn’t recognize the update. So I’m suck with the initial version published to server 2. Does that make sense?

  22. Bart Thieme Says:

    I tried this with Visual studio 2012 with my unsigned application but got this error: “user has refused to grant required permissions to the application”. Is there a different method now or should it still work the same?

    • robindotnet Says:

      Where/when are you getting that error? This should still work. Is the user on Windows 8, and he’s not approving the application?

      • Bart Thieme Says:

        Thanks for the reply, but I have solved my problem by simply moving the application and performing a manual upgrade on both clients from the new location.

  23. Soum Says:

    The video doesn’t work. The message is “The requested PointAcross message does not exist.” Can you resolve it please?

    • robindotnet Says:

      The video should be working now. Sorry about that, the videos were hosted from the company I used to work for, and they disabled my account without telling me.

  24. Fedor Says:

    Video still doesn’t work, at least for me.

  25. Rick Bowden Says:

    Hi Robin,

    Great post but I’m having some problems getting this to work.
    My app is published to a server file share \\server\share\folder.
    It installs and updates fine but i wanted to test moving it to another location.
    I followed your instructions but the app just updates to the intermediate version in the original location and doesn’t pickup the new url.
    I am changing the assembly and file versions each time, could that cause issues?
    Also the new location is just another folder on the same server and has a space in it.

    Any ideas?


    • robindotnet Says:

      Go through the instructions and try it again. I tested this using file shares as well as URLs, and it worked fine. And you *want* to change the version each time. I’m assuming you’re incrementing it. And just for grins, try it with a folder without a space in it. Stick an underscore in there and see if that helps.

  26. rhonda Says:

    videos are nice and all … but a quick text summary (even without screenshots) would be awesome for those of us with short memories – to refresh what we had to do last time. 🙂

  27. Update ClickOnce installation to a completely new application - BlogoSfera Says:

    […] know that I can change the installation URL path using this technique, but is it also possible to change the application name? Ideally I would like to uninstall the old […]

    • robindotnet Says:

      Sorry, you can’t change the application name this way. It is part of the unique fields that make up the deployment’s identity. It won’t pick up the new version from the file if the application name is different.
      I had a case where I was trying to do this, and I wrote a small console app that would uninstall the current application and then call to install the new one. That would totally work for you.

  28. tomgowansuk Says:

    Great tutorial, you wouldn’t happen to have a copy of the source code from the old msdn link originally provided? Source is no longer available on msdn

    • robindotnet Says:

      Dang it, I don’t have a copy of that code, and you’re right, the URL is dead. I don’t remember there being any code around it, just how the URLs are set. If I run across the code, I’ll post the URL here.

  29. Honglin Says:

    Hi robindotnet,

    Learn a lot from this video, thank you.
    I have a question, if I put the version v1.3 on both TESTURL 1 and TESTURL 2 directly, what is the matter?

    v1.1 will check for update on TESTURL1, and find v1.3 directly.
    Now on Win 7 and Xp, this method works, but not on Win 8, could you please point out the reason?

    • robindotnet Says:

      There is no reason it would work on windows 7 but not work on windows 8. Have you tried enabling the enhanced logging to see what’s really going on?

      • Honglin Says:

        Hi robindotnet,
        I mean I did not put v1.2 on either TESTURL1 or TESTURL2, on windows 8 or 10, it will be failed with message “user has refused to grant the permission for this application”. I think the security setting on windows 8 or 10 are different from Windows 7.

        • robindotnet Says:

          As noted in the articles about Windows 8 (which also apply to windows 10), I noted that the customer is going to be prompted by the smart screen filter. They have to actually click something like “install anyway” or “more info” to override that filter.

  30. David Slade Says:

    hi Robin,
    Yes, this no longer works for my apps, something has changed, using VS2013 NET 4. I made test sites called TestClick and TestClick1 using your example.
    Error message when trying to move from TestClick to TestClick1:
    You cannot start application TestClickOnceWpfApplication1 from location http…./TestClick1/TestClickOnceWpfApplication1.application it is already installed from location http… /TestClick/TestClickOnceWpfApplication1.application.

    Used to always work some time ago, now fails.

    • David Slade Says:

      I got the answer to my problem: Initially the update location must be blank for the version to be moved, when it is first published, as you did in your V1.1. I have been setting it to the same as the publish location, thinking that would have no effect. Not sure where this is stored, could not find it in manifest, but it does block moving the app to the new location later.
      Also I think you need to make sure the Option “Exclude deployment url” is not checked too. Hope this helps others.

      • robindotnet Says:

        You don’t have to exclude the deployment URL. When the user has the app installed, if the update URL filled in, it will go there for the update instead of to the original deployment URL.

    • robindotnet Says:

      It looks like those are two different applications. The application name is part of the security of ClickOnce; if you change it, it does not recognize it as the same deployment.

  31. Ægir Sveinsson Says:

    Wonderful – Thanks a lot Robin. You really helped me out here🙂

    Best regards,

  32. Nikola Novak Says:

    Hi, will this work if I were to publish 1.2 (as from your example) without publishing 1.3 previously? The idea is to publish a version that will simply look for *future* updates at a new location which currently has no updates. I need to keep the old server around until all users are updated anyway, so there really is no rush to move to the new one immediately.

    • robindotnet Says:

      It won’t work. You have to have the new version available. Note that you can take the old version and increase the version number using mage or mage ui, re-sign the manifests, and put them on the new server. So it looks like a new version and will install, but nothing has really changed. Otherwise, just don’t do the move until you’re really ready.

  33. lmgc92 Says:

    can you publish the same project from different computers and different users?

    • robindotnet Says:

      You can do this only if you are using the exact same signing certificate. If they are different, Click Once may treat it as a different version and install it again, resulting in having multiple entries in the start menu.

  34. Lucas Carol Sales Duarte Says:

    You can just use url rewrite at web.config, the old program will point to the old url, but it will bring the new program, which will have the new url.

    • robindotnet Says:

      Have you actually tried that and verified that it works?

    • Arnaud Maichac Says:

      Hi, I just tried and unfortunately it doesn’t work. You will get a DeploymentException saying the application is unable to start as it is already installed from a different location.

  35. indhu Says:

    can we do this programmatically to update the url f other locations

    • robindotnet Says:

      I’m not sure what you mean. You can write something to modify the URL and re-sign the manifests, but you could also just edit it with notepad and re-sign with mage.

  36. Jeryko Says:

    Hello Robin,
    Thanks a lot for your explanation. This is a great solution.
    However, i’ve a question about a new issue (without use v1.2 during process). Can you tell me if it’s okay ?

    The new order :
    1) Publish v1.1 in server1
    2) Publish v1.3 in server2
    3) Publish v1.3 in server1 with update to server2 (with same parameters showed in video)

    Have a nice day

    • robindotnet Says:

      I don’t think it will work, but feel free to try it out. I don’t understand why you would need to do that. If you are using forced updates, when the customer runs v1.1, it will update him to 1.3, assuming you have set the update URL to server 2.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

Join 85 other followers

%d bloggers like this: