I have a Windows VM in Azure that I'm using for VS2015 experiments.
Google Drive is unable to contact update servers to finish its own installation (despite Chrome/Omaha working fine).
Apparently, I also can't clone git repos over ssh, even though HTTPS seems to be working.
Disabling the Windows Firewall does not seem to remedy these issues.
Suggestions?
You have to open endpoints on the vm. HTTPs and HTTP are open. If you need other ports...then you need to find them and open them as endpoints. My guess is that's what is happening here.
Related
Good morning,
Working on installing Meteor on windows using the following guide:https://gist.github.com/gabrielhpugliese/5855677
As pointed out on other posts its a little dated and I needed to install meteor separately, which I used this guide: Unable to install meteorite on Ubuntu VM
Currently, my set up can do the following:
files stay in sync between vagrant and windows
localhost:3000/ is working on the server
What I still need help completing:
when opening localhost:3000/ in my windows browser, I get the "This webpage is not available
I know that the vagrant VM is correctly serving the app because I opened a new instance of vagrant and curled the localhoust:3000/
I am actively working in django and node and can successfully run apps locally on :8000 and :8080, I tested the meteor app on those ports but still couldn't connect. I also created a windows firewall port exception on 3000 but the results didn't change.
I know that there is a windows-preview currently out, but that is not working for me and I have an issue being tracked in gitHub.
Thank you in advance.
One thing that might be worth mentioning is it is somewhat possible to use Meteor on windows.
More details here: https://github.com/meteor/meteor/wiki/Preview-of-Meteor-on-Windows.
With your vagrant machine it sounds like there is a problem with port forwarding on your localhost machine to the VM's ports.
One possible simple way to get passed this is to get your Ubuntu machines IP address and simply load it up using http://<ip address>:3000.
I'm not sure why the port forwarding isn't working on your machine. In general the reason is provided when you run vagrant up, if there was an issue.
Running Mavericks on Macbook air, Nitrous box with simple test app bundles and runs fine on Meteor host but is not accessible on browser via 'preview'.
Bit baffled. No firewall running and unsure how to proceed.
I am having the exact same problem with Nitrous.io right now. I am betting this is an intermittent problem. A few hours ago I could access sites running on that box just fine from my local machine.
Fiddler tells me:
No connection could be made because the target machine actively refused it 54.217.184.231:80 so this points to a server-side problem. Seems we have to wait.
I’m having many troubles installing WebSitePanel on an Azure Virtual Machine, with Windows Server 2012.
I followed the steps in http://www.websitepanel.net/documentation/deployment-guide/server-configuration/preparing-windows-server-2008-r2-for-websitepanel-installation/ and installed everything I needed.
Then, I installed the WebSitePanel Standalone Server package with the installer.
I opened the endpoint for the port 9002 on Windows Azure; so I pointed my browser to myhostname.cloudapp.net (note: in Azure you don’t have a static IP address, instead you have an hostname like [hostname].cloudapp.net).
So, loading myhostname.cloudapp.net:9002 fails, and any browser shows something like “Unable to load page”. I think it’s a 400 or a 500 server error.
How come?
IIS works perfectly on the server, in fact the default website runs without problems on port 80.
This issue occurs when you change the binding to another IP address.
Usually I fix this situation by going to the IIS control panel where I change binding back to 127.0.0.1:9002
In case you haven't found the correct solution yet :
edit your hosts file under system32/drivers/etc and put the url you have set up during the installation there with your local ip
You should be able to access websitepanel portal with the url
I have a XP Pro and Vista machine setup on a workgroup LAN, normal case
with NAT router/adsl modem. Latop is wireless.
The XP Pro laptop has IIS on it and I have written an ASP.NET app.
When I try to access the app from browser on the Vista PC I get an error
saying can't connect to site.
I have tried the following:
Can ping the XP Pro PC from Vista PC.
Turned on Web access from windows firewall.
Rebooted.
When I telnet to it I get http 400 bad request.
Any thing I am not doing please?
Malcolm
Are you debugging your project using the ASP.net development server? I believe that server does not accept external connections.
If you've allowed access through the firewall, I'd suggest looking at your IIS settings for the website. Is anonymous access allowed? What sort of authentication are you requiring if not? Is the website actually running in the url you're requesting?
Lots of different problems occur because of IIS settings. Play with each possible cause, one at a time, until you find out what it is the real cause, if you still can't find it, play with two at a time.
When you finally find the problem, REMEMBER it, because problems with IIS tend to be forgotten and then you have to go through everything AGAIN. Sadly, I know this from experience.
Developing an ASP.Net website.
Running IE8.
Need to test website under IE6.
MultipleIE6 install broken by IE8 install (can't type in textboxes, yes I deleted cache, yes I re-registered the dll's).
Created VPC running IE6.
Can't connect to host WebDev.WebServer.exe.
Is there any way to configure WebDev.WebServer.exe so that it will accept remote connections?
The workaround for the way that webdev.webserver is crippled to refuse remote requests is to use a lightweight proxy server running on the same host as webdev.webserver. The remote browser then uses the proxy and its requests appear to webdev.webserver like requests originating from localhost. I've used Privoxy succesfully.
Sample config:
Configure Privoxy to listen on an IP
address that is routable from your VM
(eg 192.168.1.1:8118). You can put an IP address on a looback on your host OS and use NAT with the client OS.
Configure your browser(s) in the VM to use
192.168.1.1:8118 for its proxy for all connections including localhost.
Start your app in webdev.webserver
With your VM browser go to the same URL as you would with a browser on your host OS (eg http://localhost:3254)
From the perspective of webdev.webserver the requests will originate from Privoxy on 127.0.0.1 and it will happily serve them up.
UPDATE
These days, I am using Fiddler2 for this. Fiddler has an option in Tools > Options > Connections to "Allow remote computers to connect." But also note that IISExpress can be configured to accept remote connections.
AFAIK, WebDev is coded to specifically reject all external connections... so the short answer would be "no".
Best thing to do would be simply publish the website to your VPC running IIS and test it that way.
I ran into this same issue, and after some research, found that the method detailed at this site worked for me:
http://www.funkymule.com/post/2009/04/17/Making-ASPNET-Development-Server-Listen-for-Remote-Connections.aspx
It involves modifying and reassembling the Webdev server and DLL, but once it's all up and running, I've been able to use older versions of Internet Explorer running in VPC/XP Mode to connect to the WebDev server running on the host machine via the internal network IP (192.168.x.x).
Hmm i am not shure this works, but try adding the WebDev.WebServer.exe to be unblocked from your Windows Firewall.
If this doesn't work you have to install IIS and set a virtual directory directly on your development folder.
I use one of Microsoft's VPC images to test IE6 using the debug webserver, so I don't know what could be causing your issues. Sounds like it could be a networking issue with the virtual machine.
Also IEtester works well for quick checks of rendering and functionality. I have yet to see any major differences between the behavior in IEtester and the real IE6 under XP, but the possibility exists so I still check with the virtual machine before release to production.
http://www.my-debugbar.com/wiki/IETester/HomePage