none
Remote desktop collection is missing properties I would like to add RRS feed

  • Question

  • Hello everyone,

    I am using Server 2012 Datacenter in a VMware environment. What I am trying to do is have one of our Remote Desktop collections, when clicked on through RD Web Access, already have the computer name and the RD gateway server when open/launched (custom .rdp file).

    I have seen articles saying in 2008 server you could do this through a GUI, but with Server 2012, Server Manager doesn't allow you to add the custom properties I am looking for. Instead, it is suggested, well implied, to use powershell. Below are the options I'd like to add but while trying to use powershell, I receive the overly posted, "You cannot call a method on a null-valued expression." At looking at the Set-RDSessionCollectionConfiguration command, no where on the page does it say it returns an object/value/something, and all variables I pass accept strings. I know I am missing something but I am unsure what. Here is a how I am trying to use the above command:

    Set-RDSessionCollectionConfiguration -CollectionName "Faculty" -CustomRdpProperty "full address:s:Server.SomeDomain.ORG"

    Below are several other properties I'd like to add where I have found that by adding `n in between commands, it should work, but I wanted to start with one property before jumping ahead. In addition, I'd like to add a custom certificate but that isn't as important as getting the computer name and default gateway addresses to show up, and not have the end user type it in. 

    gatewayusagemethod:i:2
    gatewayprofileusagemethod:i:1
    gatewaycredentialssource:i:0
    full address:s:Server.SomeDomain.ORG
    gatewayhostname:s:Server.SomeDomain.org

    I appreciate everyone for reading this and look forward to any help and/or insight. I had links to articles/technet but because my account is not verified yet, I couldn't link to them. If you have any questions, I will be more than happy to assist.

    Sincerely,

    Mike

    Monday, July 17, 2017 7:46 PM

Answers

  • Hi Mike,

    I understand what you mean, but it is likely that the powershell command is failing for the same reason the settings are not being included automatically in the .rdp file as they should.

    At this point I suggest you rebuild your RDS deployment database during off hours.  To do this you would first take a backup and/or snapshot of the VMs, make a list of your collections, published RemoteApps, deployment settings, collection settings, etc.  Next remove RDSH servers from your collections via Server Manager or powershell, then remove them from your RDS deployment (again using Server Manager or powershell), leaving RDSH Role Service installed on the VMs themselves.

    Next you remove RD Connection Broker Role Service from your broker, which will wipe out your RDS deployment.  Restart your broker, then use Server Manager -- Add roles and features -- RDS install -- Standard -- Session-based -- etc., to create a fresh RDS deployment.  Finally you need to re-create your collections, publish RemoteApps if needed, apply certificates, apply any custom settings/permissions/etc. to your collections and deployment.

    Once you have finished recreating the deployment please test to make sure things are working properly and the .rdp files now contain the proper settings.  If you have any "phantom" icons appearing in RDWeb you may need to remove old registry keys from the broker as I mentioned above.

    Unless you have a ton of customizations, published apps, etc., the above can be completed in relatively short amount of time, say less than 30 minutes.  The reason it shouldn't take much time is you are essentially just rebuilding your RDS deployment and leaving all of your installed windows applications alone.

    Thanks.

    -TP

    Thursday, July 27, 2017 12:47 PM
    Moderator

All replies

  • Hi Mike,

    If you could explain more about what you are trying to achieve it would be helpful.  Reason I ask is, on the surface it is not clear why you need to use custom properties for your case.  Some things to consider:

    Normally if you need to change the published FQDN for the RDS deployment it is preferred you change it for the deployment as a whole.  You can do this using Set-RDPublishedName.  To be clear, this will be the FQDN that shows up on the prompt next to Remote computer: <fqdn> and should have a corresponding DNS A record on your internal network pointing to the private ip address of your broker.

    The FQDN for your RD Gateway server is normally configured via Server Manager -- RDS -- Overview -- Deployment Overview -- Tasks -- Edit deployment properties -- RD Gateway tab, or via equivalent PowerShell.  Same tab will allow you to configure the RD Gateway settings.  Once you have this done the gateway-related settings you mentioned should appear in the .rdp files.

    I understand there are certain rare cases where you need to have a collection have settings different than the deployment, and that is fine.  I just wanted to make sure you understand how things are done the majority of the time.

    -TP

    Monday, July 17, 2017 8:16 PM
    Moderator
  • Good morning,

    Thank you for your response. I have the FQDN of the RD Gateway server in the deployment, and all DNS records set. We have a collection that works and what I am trying to do is replicate that one. The properties I grabbed are from the working collection.

    We have different settings in our collections because one is for IT with access to a different server with different vlans, while the one I can trying to create is for faculty. 

    The published name is set already and the FQDN doesn't show up next to 'Remote computer: <FQDN>'. The Set-RDPublishedName was successful. 

    Sincerely,

    Michael Sujka

    Tuesday, July 18, 2017 1:13 PM
  • Hi Mike,

    If I understand you correctly, you have existing RDS deployment, with RD Gateway and collection, and everything works fine with that, but you have a second collection named Faculty and for whatever reason the existing RD Gateway is unable to reach the RDSH due to vlan configuration.  As a result you want to use a different RD Gateway only for this Faculty collection.

    Please correct me if my understanding is incorrect.

    To do what you want you would only need to override the gatewayhostname using powershell.  So in admin powershell prompt on your broker you would run:

     
    Import-Module RemoteDesktop
    
    Set-RDSessionCollectionConfiguration -CollectionName Faculty -CustomRdpProperty "gatewayhostname:s:otherrdg.domain.com"
     

    The result should be, after you refresh RD Web page on the client PC, that when you launch icon for Faculty it will display Gateway server: otherrdg.domain.com on the prompt, and otherwise use the same settings as the other icons of your RDS deployment.  The FQDN should be same as the other collection, which would be the FQDN of your broker.

    I'm not sure what you mean by the FQDN doesn't show up next to Remote computer on the prompt.  If you run Set-RDPublishedName, and it succeeds, and you refresh the RDWeb page on the client PC, the new FQDN should show on the prompt.  If it doesn't, it could be because you already overrode the FQDN for that collection using custom rdp property.

    The idea is to only use CustomRdpProperty where absolutely necessary.  If you already have RDG working, the other gateway-related properties should be coming through in the file, so the only change you need to make is to override gatewayhostname.

    Thanks.

    -TP

    Tuesday, July 18, 2017 1:48 PM
    Moderator
  • Good morning!

    Thank you for your reply. The gateway is reachable through the Faculty collection, but when I go to the RD Web page, and click to launch the Faculty icon, it is missing both the computer name and gateway names in mstsc., yet Set-RDPublishedName was successful and the gateway is already defined in Server Manager -- RDS -- Overview -- Deployment Overview -- Tasks -- Edit deployment properties -- RD Gateway tab.

    When I run the above powershell, again I get the null-valued expression, which was the reason why I started this thread. I saved the file and updated the gateway hostname, and ran powershell as administrator, with no luck. 

    Sincerely,

    Michael Sujka

    Friday, July 21, 2017 1:38 PM
  • Hi Mike,

    Based on what you are seeing there is something wrong with the Faculty collection.  It is abnormal for a collection to not have the settings from the deployment automatically included in its .rdp file.  What I would suggest is to delete the Faculty collection, make sure its alias key is gone from the broker's registry HKLM\ SOFTWARE\ Microsoft\ Windows NT\ CurrentVersion\ Terminal Server\ CentralPublishedResources\ PublishedFarms\ <collecitonAlias> , recreate the collection, then refresh RDWeb and see if proper settings are in .rdp file.

    -TP

    Friday, July 21, 2017 1:56 PM
    Moderator
  • Hello again,

    I deleted the collection, created a new collection with a new name, opened up RD Web Access, launched the icon, (made sure the reg key wasn't there) and to still no avail, the gateway and computer fields were not filled in. 

    I know things should work through Server Manager -> Remote Desktop Services, but if I could get the above powershell commands to not throw a null-valued expression I would be golden, at least for now. 

    Sincerely,

    Michael Sujka


    Friday, July 21, 2017 2:28 PM
  • Hi Mike,

    I understand what you mean, but it is likely that the powershell command is failing for the same reason the settings are not being included automatically in the .rdp file as they should.

    At this point I suggest you rebuild your RDS deployment database during off hours.  To do this you would first take a backup and/or snapshot of the VMs, make a list of your collections, published RemoteApps, deployment settings, collection settings, etc.  Next remove RDSH servers from your collections via Server Manager or powershell, then remove them from your RDS deployment (again using Server Manager or powershell), leaving RDSH Role Service installed on the VMs themselves.

    Next you remove RD Connection Broker Role Service from your broker, which will wipe out your RDS deployment.  Restart your broker, then use Server Manager -- Add roles and features -- RDS install -- Standard -- Session-based -- etc., to create a fresh RDS deployment.  Finally you need to re-create your collections, publish RemoteApps if needed, apply certificates, apply any custom settings/permissions/etc. to your collections and deployment.

    Once you have finished recreating the deployment please test to make sure things are working properly and the .rdp files now contain the proper settings.  If you have any "phantom" icons appearing in RDWeb you may need to remove old registry keys from the broker as I mentioned above.

    Unless you have a ton of customizations, published apps, etc., the above can be completed in relatively short amount of time, say less than 30 minutes.  The reason it shouldn't take much time is you are essentially just rebuilding your RDS deployment and leaving all of your installed windows applications alone.

    Thanks.

    -TP

    Thursday, July 27, 2017 12:47 PM
    Moderator
  • Rebuilt, and everything works.

    I appreciate your assistance!

    Sincerely,

    Michael Sujka

    Wednesday, August 9, 2017 7:24 PM
  • I appreciate this thread is over a year old but just wanted to add my findings for any one finding this thread with the same problem.

    I inherited a RDS deployment with 2 collections and a number of published apps. When trying to add a new collections the RDP file deployed to the client was missing a significant number of properties and wouldn't work. Using Set-RDSessionCollectionConfiguration would return the same error Michael was having. It turned out to be the certificates in the deployment were expired. All existing collections/apps would work but it wasn't possible to create new collections.

    Hope this helps someone.



    Tuesday, December 11, 2018 7:38 PM
  • Thanks Vítor. This helped me.

    I didn't have the exact same issue but re-installing the Certificates via Server Manager, even though they were the same, has resolved the issue for me.



    Systems Engineer

    Monday, June 24, 2019 11:57 PM