I'm using the BlazeDS binary version with Apache tomcat 6.0. And it seems there's a developer mode active and it only allows 3 IPs to connect to the application (Server).
This is what the log says:
[BlazeDS]MessageBroker '__default__' rejected connection from address 'xxx.xxx.xx.x'; Developer mode addresses already in use: xxx.x.xxx.xx, xxx.xxx.xxx.xxx, xx.xxx.xxx.xx
(IP addresses are masked with 'x' for privacy)
I have not added any special configuration to make developer mode active. I couldn't find any resources related to this scenario either. Please help.
Thanks in Advance.
If you install Livecycle DataServices without having a serial number you'll have this limitation. However that's not the case for BlazeDS. So please check again, I think you have installed LCDS instead of BlazeDS.
Related
I want to create a VPN Connection Manager on user's PC. The connection Manager must set up 3 VPN protocols on user's PC for Windows XP, Windows Vista, Windows 7 and Windows 8.
PPTP and
L2TP/IPSec and
OpenVPN
The Connection Manager shall receive server list from our servers.
Please help me to soulve the above issue. I google it since last 2 days bit not find any approproate solution to this. So please help me in this.
You can find details on creating a VPN Connection in .NET using:
Set up VPN Connection using C#
Remote Access Server Spec
However using ASP.NET is unlikely as browsers can't instantiate a VPN connection, they are sandboxed away from that functionality. Even services like GoToMyPC have a desktop client to perform the main functionality.
However you could create the RAS file then provide a download link on a website to it.
You can find the file at:
C:\Documents and Settings\All Users\Application Data\Microsoft\Network\Connections\Pbk\rasphone.pbk
The person downloading the file can then just import that and have all the set up provided.
This may be a general topic, but I came across the issue while working on some code using the Rook package.
The recent R versions include an http server. You may have seen this while checking for help topics using RGui. It opens a new browser with the IP/Port, etc.
For eg., if I enter ?paste, this brings up,
http://127.0.0.1:31234/library/.../paste.html
But if I use my IP, say 192.168.1.2 in place of 127.0.0.1, the page fails to load, I get an error
While trying to retrieve the URL:http://192....
The following error was encountered:
We can not connect to the server you have requested
I have other apps that have httpd interfaces, and I can go to those app's http interfaces using both 127.0.0.1 and 192.168.1.2 ... etc. So, as far as system/network permissions are concerned - I do not think that is the issue here.
Rather, there is something specific to the R httpd process that disallows it to be accessed using the domain name, etc ?
The above was tested in a corporate network. When I tried the same process from my home network it worked fine. However, since I already access http interfaces of many other locally installed apps from the corporate PC, I think there might be something specific to R's http process that needs to be checked ?
Workstation is running - Windows XP
Please let me know if you have any thoughts on the above,
Regards,
Raj.
Fixed it. The trick is to specify,
s <- Rhttpd$new()
s$start(listen="0.0.0.0",port="20000")
when starting the Rook process. Specifying 0.0.0.0 makes it listen to all the interfaces and now I can access it using my external IP. Thanks a lot for your help nonetheless !
When opening a TCP port, the local IP address may be chosen. For incoming connections, typically INADDR_ANY (-1) is supplied to bind(), which means to open the port on every available interface.
However, it is quite possible to open a port on just one interface on your machine (in this case, 127.0.0.1), simply by supplying the IP address of the interface. Seems that R does just this.
My guess is that you may have a proxy in place on your corporate network. Your browser is probably configured to use that proxy to access the Internet. Most browsers will exclude an address which they know to be local (127.0.0.1 or localhost) from using the proxy, but might not exclude any other IP.
Try disabling the proxy in your browser (even "Auto-Detect", completely turn the proxy off) and see if you're able to connect.
I had the same problem.
If you are using RStudio, this might be a bug in the RStudio. Check out this link:
https://support.rstudio.com/hc/communities/public/questions/202656007-Cryptic-error-on-starting-RStudio-daily-with-R-devel
Updating to the latest version of RStudio with the latest version of R fixes the problem.
I just got IIS7 set up on a Windows Server 2008 R2 machine in VirtualBox. After doing so, I could not connect from any other client, though http://localhost worked. For that matter, I was unable to even ping the server.
After doing some research, I found that enabling File and Print Sharing on the server solved the problem, but surely there has to be a better way, and I would much prefer to learn to use the best method, rather than the easiest one.
What, specifically, should I do to enable both pinging of the server as well as access to the web server running on it?
Isn't it that the inbound web HTTP port is blocked by default? I'm not a server guru but can remember going to the firewall to allow it through. Should already be there.
Out of the box on Windows Server 2008/2008R2 firewall is installed and users cannot access resources or services on the server unless you configure exceptions to the firewall. There is one exception to this are services/resources on this server that you make available through the GUI tools (Initial Configuration Tasks Wizard, Server manager) - these automatically create firewall required exceptions for you.
So in your case either upon File and Print Sharing installation or upon using File and Print Sharing config wizard/Shared resource provision wizard (most likely the later) required firewall exception was created for you. The rule in question is: File and Printer Sharing (Echo Request – ICMPv4-In) - actually allows ping, but I guess Windows also uses it for network resources discovery and other things implied by the role you installed.
Nothing prevents you from not enabling File and Print Sharing and just enabling mentioned firewall exception manually.
I need to know what is the protocol used in vmware ESXi vSphere client to connect to the remote console?
Is this protocol open source ?
Is their any vmware/third party applications enables VM Remote console connection other than vsphere client ?
If you're looking to connect to a ESX machine, without the heavy overhead of the vSphere client then you can use the VMware Remote Console.
While this isn't formally documented, one of the developers has kindly posted some fairly detailed information on the VMware Forums.
vmware-vmrc.exe command documentation
Depending what version of the plugin or vSphere client you have installed depends on the exact location of the plugin. Here is an example for what I have installed as part of vShpere 5
"C:\Program Files (x86)\Common Files\VMware\
VMware VMRC Plug-in\Internet Explorer\vmware-vmrc.exe"
-u user -p password -h esxi.localnet -d "[store1] Test/Test.vmx"
VMware's console access is indeed a closed protocol. However, they do have an embeddable web control called the Remote Console that implements this. It is an 'experimental' feature I believe, and won't be supported by them. But it's doable.
So while the protocol isn't implemented by anyone else I know of, there is an option to wrap the control at least.
See: Installing and Using the VMware Remote Console Plug-in
I have an application that runs transactions spanning over multiple databases on the same server. Naturally this involves the Microsoft Distributed Transaction Coordinator and everything works like it is supposed to.
Howver, when I remotely connect to the network where the server is hosted via VPN and run the application on my local machine I receive the following error:
System.Transactions.TransactionManagerCommunicationException:
"Communication with the underlying transaction manager has failed."
Caused by:
System.Runtime.InteropServices.COMException:
Error HRESULT E_FAIL has been returned from a call to a COM component.
Here is the stack trace for the originating exception:
at System.Transactions.Oletx.IDtcProxyShimFactory.ReceiveTransaction(UInt32 propgationTokenSize, Byte[] propgationToken, IntPtr managedIdentifier, Guid& transactionIdentifier, OletxTransactionIsolationLevel& isolationLevel, ITransactionShim& transactionShim)
at System.Transactions.TransactionInterop.GetOletxTransactionFromTransmitterPropigationToken(Byte[] propagationToken)
The problem arises only when I connect to the server through a VPN tunnel.
Note also that I have temporarly disabled Windows Firewall on my local machine, just to be sure it doesn't block the MSDTC.
Does anyone know of any issues when running MSDTC through VPN?
I suggest you run DTCPing (available from the Microsoft site somewhere) This is run at the same time on both machines and detects all manner of DTC problems.
Be careful I had great difficulties with this tool until I actually read the instructions and started both sides of the test up before I clicked the start test button.
Do you administer the VPN connection? There might be restricted ports on the VPN. Likewise, do you administer your servers? Your servers might only allow connections from IP addresses on the inside and not on the segment used for VPN service. If you are the administrator, perhaps saying which VPN software you are using will help.
I'm having the same problem using a Windows 7 x64 client and a Server 2003R2 server. I have been able to make it work (on the same vpn, same server) using XP, Vista x86, and Windows 7 x86. I have a support call with Microsoft open and they are looking into it. I'm curious - what operating system are you guys using on your client machines?