The Windows 8 simulator which comes with Visual Studio 2012 does not launch either via debugging in Visual Studio or by running it directly.
As the simulator used remote desktop (RDP) and the issue occurs within Visual Studio & if I start it directly. I have identified that if my VPN is NOT enabled, then the simulator works fine. Thus I believe the issue is between VPN & RDP.
In the event log for RDP (Application and service logs - Microsoft - Windows - TerminalServices-RDPClient) I see the following message:
RDP ClientActiveX has been disconnected (Reason= 5639)
Reason 5639 is The policy does not support delegation of credentials to the target server.
Are there any policies in group policy that I can change to enable delegation of credentials?
I have also tried turning off the firewall, setting RDP to all users and running the simulator as administrator but none of those options have helped.
The Solution was to set the checkbox Automatically use my Windows logon name and password (and domain, if any) in the VPN security properties, as shown below.
I got same issue, and it's also due to a VPN connection. As my computer is not on the office domain, I cannot check "Automatically use ..." option.
If you have same problem, you just have to disconnect from VPN on first simulator launch, then reconnect and continue to work!
Related
I'm having issues with ASP.NET Core 6 app on my VPN Windows server 2019. Basically, I have Syncfusion OCRProcessor with tesseract files, but my application can't find part of the path for tesseract binaries on server when locally is working fine (on server error message is "cannot find part of the path C:\inetpub\wwwroot\myapp\x64").
After contacting Syncfusion support didn't solve the issue, I have checked for permissions in file system, double checked the locations of the binaries on IIS, checked if dll's are blocked in from Windows in file system. I have tried to connect from my machine with VS 2022 Community to my VPN server (public IP address) to try to debug the application, but going trough all the documents about remote debugging, still I can't connect to my app and hit the breakpoint in code to determine what is happening..
I have installed remote debugger for VS 2022 onto server, configure it and started, I have published application again over web deploy with debug config to IIS, but I just don't understand next step - how to attach to the process on external server..
Most of the videos and documentation suggests that IIS is installed locally on development machine, or IIS is on some PC in local network, but I have public server.. Can anyone help with the advice how to proceed further?
Thanks!
Ok, I have managed to connect debugger from VS 2022 to IIS.
The issue was in port, firewall and also in description on Microsoft help site https://learn.microsoft.com/en-us/visualstudio/debugger/remote-debugging-aspnet-on-a-remote-iis-7-5-computer?view=vs-2022 where in step 3 is written "Set the Qualifier field to and press Enter." - you need to enter ip address and port into connection target textbox.
After succesfull logging in onto server, I needed to select w3wp.exe process with title "CoreApp: https://.. ", set breakpoint in VS 2022 and open ASP.NET Core app in browser. After that I managed to debug application on IIS.
Hope this would be helpful to someone!
I have an application that has an embedded Microsoft webbrowser ActiveX control. On the server where the application is installed - it runs fine (runs quickly, runs scripts) within the application. The application is exposed via RDP for users to run - the Microsoft webbrowser ActiveX control page does not work properly (hangs for a long time - finally displays script error message - scripts don't work) when it is run using an RDP session.
When directly accessed from any computer, the webpage that is contained in the ActiveX control runs fine.
The application.exe files are in these registry folders with the appropriate decimal value (11001):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION
I'm thinking that there is something more that I need to do to either force the version emulation or permit scripts.
Server is 2012R2 64-bit OS
Make sure client browsers are supporting ActiveX
Set sufficient permissions for clients Explained Here
Change Security Layer and User Authentication to a hexadecimal 0 in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal
Server\WinStations\RDP-Tcp
You can do this via Regedit
Reboot the server
I found that Internet Explorer on the server was pointing to an old proxy server that was likely finally removed from service. I updated the proxy server to the one that is used by the clients and it works fine.
I have been trying to run debugging within SQl server management studio and for some reason the debugger has just stopped working.
This is the message I get:
Unable to start the Transact-SQL debugger, could not connect to the
database engine instance 'server-sql'. Make sure you have enabled the
debugging firewall exceptions and are using a login that is a member
of the sysadmin fixed server role. The RPC server is unavailable.
Before this I get two messages, one requesting firewall permissions and the next says 'usage' with some text that makes little sense.
I have looked at the other similar answers on there for the same message which suggest adding the login as a sysadmin but that is already set. I also tried adding sysadmin to another account but that also didn't work.
In the end I was able to start it by right clicking and selecting run as administrator.
I encountered this issue while connected to SQL using a SQL Server Authenticated user. Once I tried using a Windows Authenticated user I was able to debug without issue. That user must also be assigned the sysadmin role.
This happened to me and I could not find the resolution anywhere. My firewall is disabled so I knew that couldn't be the issue.
According to Microsoft: Configure firewall rules before running the TSQL Debugger:
The server needs to communicate back to the client via RPC. The
account under which SQL Server service is running should have
authenticate permissions to the client.
We had a group policy that was preventing this:
Deny access to this computer from the network (Local account, Guests)
In order to resolve the issue, I had to add the SQL Server service account to the local group "Remote Desktop Users" on my desktop. Hope this helps someone else resolve this frustrating issue.
I try with the following steps, but it did not work (maybe because I'm on a PC in a office and I don't have control of the firewall). But you can try the following.
Check the users role:
IF IS_SRVROLEMEMBER ('sysadmin') = 1
print 'Current user''s login is a member of the sysadmin role'
Follow these instructions:
configure the transact-SQL Debugger
Run SQL Server Management Standard Edition 64 bits (with SQL Server Account)
In my case, I received this error message:
Unable to start the Transact-SQL debugger, could not connect to the computer "local".
I end up close the existing connection, then reconnect to my local SQL server using IP 127.0.0.1 and it works.
What helped me, was from here:
SQL Server Management Studio must be running under a Windows account that is a member of the sysadmin fixed server roll.
The Database Engine Query Editor window must be connected by using
either a Windows Authentication or SQL Server Authentication login
that is a member of the sysadmin fixed server role.
So, I've added sysadmin role to my windows account and run ssms as administrator. Debugger started working normally.
In addition to above works, what make our 2 computers remote debug able, was running: (right click on Window's Start button)
System--> Advanced System Properties-->Computer Name-->Click on Network ID... button
and running that wizard to join workgroup on both computers.
I found this solution by looking at my Windows' Event Viewer and looking for a solution to errors with NetBT Source, that is related to workgroup and computer Name.
Update: after some days, it stop working again.
I had the same problem and double checked al recommended settings. At some point I disabled the firewall on the database server and it worked like a charm. By enabling and checking the Firewall log I noticed this entry:
2019-10-31 16:07:50 DROP TCP 192.168.xxx.xxx 192.168.xxx.xxx 65231 61214 52 S 56576751 0 8192 - - - RECEIVE
When I allowed TCP port 61214 (Inbound rule) and switched the firewall back on, it worked. I don't know why this port is needed, maybe some here on SO?
Anyway, maybe the firewall log can be of help too.
Struggled through many hours and got the answer
You can do the configuration through this doc
https://learn.microsoft.com/en-us/sql/ssms/scripting/configure-firewall-rules-before-running-the-tsql-debugger?view=sql-server-ver15
(1) 2 settings need to done on the remote server where Sql server is installed
(2) 1 setting at client computer (i.e) our computer
I have updated the server recently (only those recommended security update from the windows server), after installation i had to restart the windows server, however after restarting the server, all the port are closed and I have no access with RDP (no access to sql server database, no access to tfs ...) . currently i can access to the server only over the ssl and i have access only to the cmd consul on the server. can any body help?(the server is in the ISP and it is a dedicated server).
Cause:
installation first kb2667402 then the Sp 1 update
effect:
No RDP available
Windows blocks users right and give no right to start the services
e.x
The TFS Service uses TFSSERVICE USER, but win2008r2 block this user and say this user is not exist!
what we have done:
uninstall the kb2667402
after Uninstalling the kb2667402, i have exported the installed update and proved that the updated has been successfully removed.
delete and copy the old version of the rdpcorekmts.dll in system32
reconfiguration of the RDP and add a new port and rule for firewall
reset the firewall and add the new rule (we made a back up)
add the Teamviewer portable version with a fix password, but we cannot access to the TV, "Authentication rejected"
Installed RAdmin--> no access: the user name or password is wrong!
try to connect with Computer management from my pc to the server and get the error: RPC Sever is Unavailable
I have stop the firewall and had access from my pc Event Viewer to remote server and could follow the errors on the server.
Problem reported
http://support.microsoft.com/kb/2667402
http://tmkilla.com/2012/04/windows-server-2008-r2-rdp-connection-error-sp1-kb2667402/
I have tried all the thing but didnt solve the problem. an idea how to solve the problem?
I have done some research, based on the problem that my single server gives me when I try to open a document library in windows explorer from the ribbon menu item "Open in Windows Explorer".
The same problem occurs when I try to map sharepoint to a folder in windows explorer too.
The error is:
Your client does not support opening this list with Windows Explorer
From the net, suggestions are:
(Since I'm trying this operation from server itself) enable Desktop Experience
Install the KB907306 update.
Enable IIS webDav service (Some say, it's just for additional functions from the MS Whitepaper)
(Edit) Started webClient service
I've already done them. Nothing changed. Proper machine restart and iis too have done.
Need some serious advice.
Thanks in advance.
Not sure if we are having exactly the same problem BUT I have had similar problem while accessing SP via Windows Explorer in Windows Server 2k8.
What I done to fix it is following:
Install new server feature called Desktop Experience (it comes with WebDAV redirector, which allows you to connect to WebDAV) - Note: Server will need to be restarted.
In Services start WebClient service (go to properties and make sure it starts automatically)
You will now be able to access your sharepoint via entering network path such as \sharepointhost\application\myawesomeapplication\ etc.
Hope that helps.
If you are trying to do this from the server, test it from a server which is not on the SharePoint farm (or better yet, a client machine). Ensure all of your testing is done from machines which are not on the farm.
Do NOT enable the IIS WebDAV service, as SharePoint provides its own WebDAV service and the IIS one overrides it in the pipeline. Enabling this service is a sure path to breaking WebDAV.
If you have SSL enabled, you may be in for a rough time getting it to work. Start by understanding how to use the 'net use' command, and the #SSL suffix.
make sure your webdav is installed as feature
make the following registry fix (http://support.microsoft.com/kb/841215) :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
Add a new DWORD "BasicAuthLevel" and change this to "2"
Restart your machine (and make sure it is enabled in IIS)
Make sure that WebClient windows service is running in the server. This shall appear in client operating systems like Windows 7, windows 8 however, on the server operating systems like Windows Server 2008, it shall be installed by enabling the server feature "Desktop experience" using Server Manager
This issue nearly killed me. I found that I was using a 64 bit version of my browser and that is'nt supported. I changed over to the 32 bit and it works.