RDWeb has not worked since installing new switches - rdp

We have installed new switches, and have a 10.X network for another location that they remote into via RDWeb. Since we made the changes we have not been able to use the RDWeb but we can use the desktop RDP app.
We ran the Get-RemoteAccessHeath command and got this back
RemoteAccessHealth
We then looked at the Remote access management to see what in an error state and found the blow picture.
Remote access management error
Attempted to restart the RemoteAccess service but received an error that it is an invalidoperation.
Any advice is welcome. The users are functional but would we would like to get that RDWeb page back up and running so they can use it remote in via a phone.
Thanks,
Matt

Related

Why is transfer from test to production of Asp.Net-Core app completely not working

We've been finalizing NopCommerce .Net Core web app which has been running great on a test server. I'm now trying to transfer the app to our production server, which did not have .Net Core. I installed the latest .Net Core hosting bundle and rebooted the server. I also have Web Deploy running on both the host and the client. I exported the app from the test machine and imported it into a newly created IIS site. After setting up the bindings - and enabling stdoutlogging, I try to see what's working, and get indication that "An error occurred while starting the application". No indication what the error is. Logs is not being written to. The event viewer tells me that:
Application 'MACHINE/WEBROOT/APPHOST/NOPCOMMERCE' started process '6980' successfully and is listening on port '41573', which is a random port not binded to.
One interesting thing I noticed on the test server is a "user" called nopCommerce which has full rights to the nopCommerce folder in inetpub/wwwroot. However this user does not show when I look at local users and groups. I am not sure therefore what this "user" is and if/how I should create it. Based on some advice from somewhere I temporarily gave everyone full rights to the nopCommerce folder, but that didn't work either.
Can anybody please aim me in the right direction?
Problem was a bad setup - access rights to subfolders of nopCommerce was one, which I solved by giving the users group modify rights. This might be a bad idea and I will do some more research. The other fault was a bad database login in the connectionString.
Ultimately I had to learn that instead of starting the app via IIS, it can be run from the command-line, and then messages and errors will be displayed in the DOS box. What to run is determined from the
I still don't know where the nopCommerce user comes from on the staging server.

Application pool account permission to run RestSharp

Recently my web server (windows server 2012 R2) got several Windows updates. Since then I am not able to run a code involving RestSharp. It fails whenever I try to initialize "new RestRequest()". Windows event log registers this error: "User does not have permission to run the resource"
I have development environment with Windows 7 where I don't see these updates. My code runs fine.
I have looked into the update history on the server and looks like the following updates may be creating these problems.
KB3074548
KB3074228
KB3074545
I have looked into documentation of RestSharp to find out whether any specific permission needed on the application pool running RestSharp code. I could not find out anything.
I am wondering whether anyone else having this problem and/or may have any knowledge about permissions required to run RestSharp request.
Really appreciate any help.
It is now working. It was just a deployment issue.

Exception error running VB.NET App from network drive Win7

We have a VB.NET applciation that is run from a mapped network drive. This works fine on all PCs expect those with Windows 7, on those we get the following:
"application generated an exception that cannot be handled" System.Security.SecurityException was unhandled
If the application folder is copied locally and run from there it works fine.
Anyone know a way aroudn this issue? I assume it is related to Windows 7 netowrk security but not sure how to work around it.
Well, normally you should get this error on all PCs, not only on your Win7 PCs. But I guess for your older Windows PCs someone has solved this issue some time ago. Read this article
http://thebackroomtech.com/2009/04/01/using-caspolexe-to-grant-net-applications-rights-to-a-remote-network-share/
how to deal with the problem. Here is an SO post
.NET Deployment to Network Share
which might help you, too.
There is a reason this error comes up, It is not a good idea to grant applications access to network shares just to run them.
.Net and Click Once makes it very easy to deploy an application to a network share and distribute it to all the client computers to be run from there.
The app can then check for updates whenever it is launched and download any changes. You get all the ease of deploying to a shared drive without mucking about with code access security policies and potentially leaving a nasty hole in your network security.

Glassfish admin console won't load

I am trying to load the Glassfish V3 admin console but I can't get beyond the log in screen. The credentials I am using are valid but it never makes it to the main admin screen.
Glassfish is installed on a server without an internet connection which I think may be the issue. On my local machine I have no issues at all. I think the admin console is trying to connect to the update center and that is the problem, is there some config that that be changed to stop it looking for updates?
Any ideas?
I had a similar problem, this issue may be relevant. More info here.

ClickOnce Online-Only Application as a TS RemoteApp

I've attempted just about everything to get our ClickOnce VB.NET app to run under Terminal Services as a RemoteApp. I have a batch file that runs the .application file for the app.
This works fine via RDP desktop session on the terminal server. As a TS RemoteApp, however, well... not so much.
I get a quick flash of command prompt (the batch file) on the client system and then... nothing...
Same goes for having it point to the .application file directly (without using a batch file) or even copying the publication locally and having it point to that.
I found a technet.microsoft.com discussion about a similar issue, but there's no resolution to it listed.
For anyone who has run into this before and got it working, what did you have to do?
We currently use RemoteApp's for everything else on that server, so I'm hoping to stick with that if possible.
The current workaround is to build and run an MSI-based installer for the app on our terminal server whenever we publish via OneClick out to the network, but this can be quite a pain at times and is easy to forget to do.
Since the app works fine via Terminal Services when run in full desktop mode but not during RemoteApp, I don't think it's anything specific to Terminal Server permissions so much as ClickOnce requiring something that isn't available when running as a RemoteApp.
The Key to getting it to work is to use Windows Explorer "C:\windows\explorer.exe". This process is the base process when you login to a full session.
If you setup the RemoteApp to use Windows Explorer and the command line argument of the path to the .application file for the ClickOnce application then it will work when launched as a remote application. Windows Explorer will flash for a second when it starts, but it will disappear then the ClickOnce application will launch.
Why does it have to be a ClickOnce application? I would consider just deploying the exe file and assemblies.
I know it only half a solution, but if the application does not change much, it might be a good solution.
I believe your problem is related to the fact that ClickOnce needs to store it's data in a special user folder called the ClickOnce application cache. Apparently because of how Terminal Services sets up user folders ClickOnce can't access this in TerminalServices mode.
See this link for more information.
http://msdn.microsoft.com/en-us/library/267k390a(VS.80).aspx
There may not be a way to do it :(
Can you launch the .exe directly? It's buried under your profile in \AppData\Local\Apps\2.0[obfuscated folders], but you should be able to find it.
That will skip the built-in update process, but if it can be launched that way you could then write code to do a manual update after the application starts.
Faced the same problem this morning and got it resolved by copying the clickonce app's directory from the user settings folder to somewhere like c:\MyApp\ - I know its nasty and not very ideal.. but good enough for me!
We recently ran across this issue and decided to post a bug report on this issue to the Visual Studio development team. Feel free to comment on the bug report. It has to be a bug in ClickOnce caused by some changes in Server 2008.
https://connect.microsoft.com/VisualStudio/feedback/details/653362/net-clickonce-deployment-not-working-as-remoteapp-or-citrix-xenapp-on-server-2008-server-2008-r2
We also have a discussion on the MSDN forums covering this issue:
http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/7f41667d-287a-4157-be71-d408751358d9/#92a7e5d9-22b6-44ba-9346-ef87a3b85edc
Try using RegMon and FileMon when starting the app - You may be able to track it down to a file and/or registry permission issue.
Also maybe check the event logs to see if anything's getting logged when the process fails.