Persistent DNS

One way you can connect to a CloudShare VM is via an RDP client using the VM's external address, which is a persistent external DNS name assigned to each VM in a CloudShare environment.   

(Clicking ‘View VM’ in the environment details page is still the best method for actively working on a specific machine as this is how we keep your environment running.  CloudShare also accelerates this RDP connection to improve overall performance.)


Each individual machine in an environment has a persistent external DNS name called external address. The external address remains static across Suspend, Resume and Revert actions. 

This means you can bookmark or save the RDP link and not worry about the IP changing.  For example, when using remote desktop connection managers or terminal services such as MSTSC, you can access that VM with the machine name instead of the External Address.  This will also maintain a VM’s external name (FQDN) for the lifetime of the environment.  

External Address in the CloudShare Web UI

To grab the external address of a VM, open the environment's Environment Details page, scroll down to the VM, click More details and you'll see it listed as External Address. 



NOTE: When first launching an environment, it may take up to five additional minutes to assign the persistent DNS once the environment is listed as ‘Ready’.  Soon after the address is generated, it will temporarily have a dummy underlying IP address, which will automatically update once it is prepared. 

Setting up Persistent DNS

There is nothing you need to do as CloudShare handles this automatically.  The Persistent DNS will be retrieved as part of machine details when creating, launching or resuming an environment. >

Persistent DNS and Vanity URLs

CloudShare has had the option of a Vanity URL as an overlay for your standard Web Access URL and this will work in much the same way. 

  • Each machine in your environment have an automatically generated DNS name
  • You can set a vanity name for one VM in your environment. The DNS name for this VM will be based on this vanity name. For example if your vanity URL is, the FQDN of this VM is
  • You can also set up an alias for the DNS and CNAME to a machine 

Note that…

  • While the FQDN will remain the same, the underlying IP address will change as the environment suspends and resumes
  • As always, machines in your environment will have to be running for you to access them directly via the persistent DNS.  In conjunction with CloudShare’s API (in TeamLabs and Enterprise), you can resume and manage your environment remotely
  • You can set a DNS alias (CNAME) with your own domain name pointing to your CloudShare VM Persistent DNS

For Long Term CloudShare users

If you are a longterm CloudShare user, you might remember VM's having external addresses with the format, in which the specific numbers assigned in this string would be refreshed each time an environment suspended. This format was replaced with the newer persistent format.


Was this article helpful?
10 out of 10 found this helpful
Have more questions? Submit a request


  • Avatar
    Chris Brown

    This is a good feature to finally see. However you mention "You can set a vanity name for one VM in your environment" but you don't say where or how. Can you elaborate on this as I would like to set up a Vanity URL. Thanks.

  • Avatar
    Peter Franks

    Hey Chris, glad you like it!  For ProPlus we have a guide for this in our forums under Vanity URLs.  For TeamLabs and Enterprise you can CNAME.  

  • Avatar
    Shai Petel

    Awesome! This would help us a lot with setting up our SharePoint for access from client machines for testing.

  • Avatar
    Erik Euwe

    Great addition! This will help us a lot with web access. 

  • Avatar
    Geoff Evelyn

    Ohhh yes! Awesome a brilliant feature will definately help a lot with client demos!!!! Many thanks!

  • Avatar
    pandan wangi

    i'm new.., begin training about this matter..
    thanks a lot for this..

  • Avatar
    Peter Franks

    Hey Vivek - internet access is kind of unrelated to this topic.  It is disabled for trial users for security reasons and will remain so.  If you are in trial and would like internet access, please contact  

  • Avatar
    vivek kumar

    if internet access is blocked , and after blocking trial account , it is not possible to reopen and re-gain our data from cloud system,  so i do not think this service is useful. and our data is protect here.  so many people dislike it. and we will feel hesitate to purchase it. i have lost my important data here in previous account


  • Avatar
    Peter Franks

    Hi Vivek, sorry you feel that way.  I'll follow up with you from our Support system. 

  • Avatar
    Eric Overfield

    An excellent feature, thank you so much for adding this. I found it to be annoying to constantly change the server address in RDC manager and that is no longer an issue.

    Thanks again.

  • Avatar
    Satya Vanama

    how do I add this persistent or vanity url to my windows hosts file so, I don't need to change it every time? 

  • Avatar
    Steve Leney

    hi Satya, why not try this?  

    Not sure why or what you'd need to change though... the persistent DNS is static... right?

  • Avatar
    Bernd Linke

    Testing the sharepoint-environment with users others then administrator, the persistent url works well on links provided "on site".

    The top links like newsfeed, sites or "about me" don't follow the url but use the internal one.

    Like that, real testing is impossible.

    You wrote that no changes have to be made server side.

    May you pls give me a hint what may be wrong?


  • Avatar
    Peter Franks

    Hey Bernd, we're not SharePoint specialists so may not be the best guides in this.  But it's likely due to permission levels of the user you created or how IIS is set up.  Check out these other KBs that might help:

  • Avatar
    Bernd Linke

    Thanks Scott for the helpful links! I'll see what the matter is and report about it!

  • Avatar
    mani kumar

    Hi Scott,

    I am able to create trust between 2 external Forests, however users of the first forest are not able to Login in other forest. I doubled checked ADNS and other entries. Everything is fine as far as I know. I am not able to Allow log on locally policy to users of first forest in GPMC, Tried with everyone and hit checknames also- not able to accept that even though I select the fist forest root as the location.

    Not able to give remote access to these forest-1 Users. How to solve this?


    Thanks in advance,


  • Avatar
    Peter Franks

    Hey Mani - you've stumped me and building cross-domain trusts isn't my specialty.  Sounds more like a question for TechNet.  Unless anyone else in the community can help you, of course!  

Powered by Zendesk