Thanks guys. I tried accessing remote registry, remote powershell and ssh but without success. I have to find out how they do their remote administration and get them to enable rdp for me. It was worth a shot though.
Try MMC and see if you can add Services for their computer. If you can add that successfully then you can enable Remote Registry and then from there enable rdp. Make sure you restart the rdp service after making the registry change.
Another method would be if you have PDQ deploy installed on another system at the location, you can try to push a ScreenConnect or similar install to the system.
There are steps one needs to take to ensure remoteability in any kind of way you are hoping for. Either through specific group policies, in the base image, during deployment, via device management software, etc. It's something they would know they did. Any MMC snap in such as remote registry will have required specific steps be taken first to ensure access that way.
The best thing to do is ask, because it takes 2 minutes to write the question, then do other things while you wait for the answer, rather than wasting time and money throwing darts in the dark.
FYI - Published apps still create a full profile on the RDS box, Just the desktop isn't presented to the user. If the application allows them to browse around, they could typically see the drive letters, the mapped printers, etc... that's why you still need to lock all that stuff down.
Thanks for the info. I will keep that in mind. I was debating about using UPD's like @wrx7m and that was my interest in this post.
Also, still planning out where to put Connection Broker, WebAccess and Licensing but that is another post.
For local profile management, UPDs are a lot cleaner. If we are not putting them on a file server across the network then a second partition/VHDX is set up for that task to keep them separate.
With the inclusion of FSLogix with RDS CALs/SALs now it's a no-brainer, IMNSHO, to set the project up on the FSLogix version.
Storage management is another reason why UPDs on a network or separate partition make sense. Keeping a local profile on the C:\ of the session host is messy and can cause issues down the road with users coming and going.
As far as the Broker/Gateway/Web put those roles on one VM but separate from the Session Host.
I think you must be missing what's going on here. This removes the requirement to integrate more directly with MS Office, instead relying on a separate library that is provided standalone from Office and thus allows saving to Excel. We've had zero issues with using this library, which is actually pretty uncommon for us.
The issue is flexibility. Using third party libraries, you can integrate with Excel or with anything else. Using the Office libraries, every user, in ever system, is bound by the limitations of the most problematic. It makes deployments more costly, and more complex.
That's true, it's the kind of self perpetuating lock-in that has served Microsoft so well. People use Excel, and they ask for saving to Excel spreadsheet, so we create the integration specially to allow Excel and not include ODF, then we help keep the industry locked into using Excel because that's all we support unless you want to just save to CSV.
As for the cost and complexity of deployments... that could be true, except that the installation of our main software is already so complex and costly that dealing with potentially installing this library is the easiest part. I think we probably only have one other developer who would be able to figure out how to install it. I've never heard of any client's IT that have been able to figure out how to install it (just calls from those who have tried), client services has to do literally every install.
What I do when I want to use mine like that is set up x11vnc-server and then run it through XRDP (and choose the console option). It's faster than stock VNC... Don't ask me why, lol. I haven't gotten instructions for that yet, I don't think.
If I remember right, after a reboot, you have to connect, close the connection, and then reconnect back using the XRDP+VNC option. I don't have any installation instructions for that setup on hand though. I can work it out and post them if you like.
This is likely where I went 'rouge' in that I didn't use x11vnc-server.. I had notes on that,.. at least I believe and have misplaced them. so I had forget that.
As I was starting to have other 'OS' Kernel issues (the mouse and keyboard wasn't working correctly) I nuked that partition from Windows, and will rebuild. Maybe it'll survive as I am of course getting grub 'errors' since that partition is gone.
Is Remmina ceashing when RDP to older servers like Server 2008 R2? That’s the only server giving me issues with Remmina. Try freerdp or rdesktop through command line and see if you have a better experience.
@dafyre I didn't ever get back to needing this until now. How were you able to achieve this? I use Fedora 28 and the Cinnamon desktop.
Sadly, no, I haven't. From what I can tell, Fedora 28 (probably 29 too) use Wayland by default. I haven't found a way to get it working yet. I tried switching the Login Screen to use X first, but even that didn't help.
Have you tried disabling Wayland instead?
I hadn't thought about that. I'll have to do a fresh install and see how that's done, unless there's a working VNC Server package in Fedora 29...
Just edit /etc/gdm/custom.conf and uncomment WaylandEnable=false and then restart. You will have only two options GNOME and GNOME Classic.
That gets me one step closer. I can get XRDP to connect to the local VNC server, but the user has to log in (locally) first... :face_with_cold_sweat: