In remote access devices i was using only iphones
I was able to mock location under auutomated test runs but not in remote access.
It is currently not possible to mock GPS location in Remote Access on Device Farm through their offerings. This is a good feature request to implement prior to starting the remote access session.
For further assistance, check out AWS Device Farm Forums where you can get assistance with your questions from Device Farm engineers.
Related
I've got 2 machines:
A corporate desktop machine which is running Windows 7 SP1 which resides on the corporate domain and which I log into using a corporate domain account.
A personal laptop that I use when working from home via the Cisco VPN client but presently sits on my desk connected to the corporate WiFi (though I had it connected to the wire and on the same subnet as my desktop machine today also). This machine is not on the corporate domain; I log into this machine with a Microsoft Account.
I need to run Visual Studio 2013 Release Management Client from both machines. The machine on my desktop works fine when entering either the IP address or the URL into the Release Management Server URL entry field and everything hooks up and all is glorious.
On my Windows 10 laptop however, it's a different story. Every attempt to connect is met with the error:
The server specified could not be reached. Please ensure the
information that is entered is valid (please contact your Release
Management administrator for assistance). <-- I'm the admin
I can ping the machine both with IP address and with hostname, ruling out DNS issues. Both client machines are on the same subnet. Both machines are using the same outbound port.
Checking the event log I see a bunch of Message: The remote server returned an error: (401) Unauthorized.
Checking with Fiddler, on my desktop machine, I can walk through the handshake of each of the stages of startup and all is good. But in Fiddler on my laptop I see 3 401 Unauthorized errors before Release Management Client bombs and returns the rather uninformative message I posted above.
I've attempted to create a shadow account on my laptop and do the Shift-Right Click-Run As Different User dance, but I must be missing something because I can't get this to run.
I've talked to the network administrator who suggests that I should be able to access all of the same resources from both machines and that it must be a Release Management issue.
Is this an incompatibility between VS2013 Release Management & Windows 10 or something else? Has anyone else had this issue and overcome it? I have access to be able to administer the Release Management environment if there's changes that need to be made there and I'm a local administrator on both machines. I'm not however a domain administrator if changes need to be made there.
I would bet you simply have a security issue as the workstation is not domain-joined and the WPF client is using Integrated Authentication.
Often creating a local "shadow" user with same username and password, and running the client app under that account (run as) works.
Another option is to join the workstation to the domain or use a domain-joined VM.
After fully investigating the situation, it appears to have been a combination of factors. I am posting a response because this appears to be a relatively common problem:
The workstation was sending an unexpected credential to the server. To get around this, you have to configure the user account on the server without a domain in the username and create a shadow account on your local machine. When running the client application, you must either log into this shadow account on the local machine or you must SHIFT+RIGHT CLICK and choose "Run as" entering your local shadow credentials. This will then pass the shadow account to the server which will now authenticate without referencing the domain. OR
Create a user account on the server that matches the credentials on your local machine including MACHINENAME\LocalUsername
There appeared to be a network issue when attempting to connect to the Release Management Server from the non-domain machine when connected inside the network. When connecting via the VPN from home, this situation was resolved, but only after we'd ensured the account and local machine accounts were correctly configured. The domain connected machine always connected properly.
We have a setup where we have both VMs and Web Apps in Azure connected to our on-premise resources via a point-to-site virtual network.
We have an folder on premise with access to Everyone open (both on the share and NTFS) and the Azure VMs that are on that virtual network are able to browse to the share without difficulty.
The web apps are not able to access them however.
I'm assuming the following line in this article explains the reason, but I'm looking to confirm this is not possible:
The work required to secure your networks to only the web apps that need access prevents being able to create SMB connections. While you can access remote resources this does not include being able to mount a remote drive.
Coming out of the logs from the attempt from the website to access it:
Taking the C# code out of the picture, trying to get the directory listing from the powershell console on the web app:
I've also tried this with Hybrid Connections, and am getting closer - once it's setup and attached to the Web App, I'm able to tcping the SMB port from the powershell console (which is further than I can get when using the VNET), but it's still unable to list a directory:
Any thoughts? Anyone doing anything similar?
The tcping result is actually misleading - you are really pinging a local port hosted on your web app (hence why the tcping has results of ~1ms). Tcping doesn't actually test the full tunnel for Hybrid Connections because the tunnel is a TCP level data relay only (that is, it does not send TCP headers, etc., over the tunnel, only payload) and tcping does not send any data, only simply verifies that the TCP handshake succeeded.
Unfortunately, the article is correct - SMB will not work at all in your Web App. There are security layers in place that will block the attempt.
I have setup FTP in IIS 8.0 on an Azure windows server 2012 virtual machine.
After followed the instructions in this post (http://itq.nl/walkthrough-hosting-ftp-on-iis-7-5-a-windows-azure-vm-2/) I've been able to make FTP work fine in passive mode, but it fails when trying to connect in active mode from FileZilla. FTP client can connect to the server in active mode but fails with timeout error message when trying to execute LIST command.
I carefully revised 20 and 21 endpoints are set in azure vm without pointing to a probe port and that windows firewall allows external connections to 20 and 21 VM ports.
I can't figure out why active mode doesn't work while passive mode works fine.
I know there are other users with some issue.
Please is there someone who had succed setting active ftp in azure VM?.
This previous response is incorrect. https://stackoverflow.com/a/20132312/5347085
I know this because I worked with Azure support extensively. The issue has nothing to do with the server not being able to connect to the client, and my testing method eliminated client side issues as a possibility.
After working with Azure support for 2 weeks, their assessment of the problem was essentially that “Active Mode FTP uses a series of random ports from a large range for the data channel from the client to the server. You can only add 150 endpoints to an Azure VM so you couldn’t possibly add all those ports and get Active FTP working 100%. In order to do this you would need to use “Instance level public IP” and essentially bypass the endpoint mechanism all together and put your VM directly on the internet and rely entirely on the native OS firewall for protection.
If you HAVE to use Active Mode FTP on Azure and are ok with putting your VM on a public IP, he provided this link:
https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-instance-level-public-ip/
UPDATE: Official response from Azure Support:
Josh,
First of all thanks with your patience on this. As I mentioned in my
last email I was working with our Technical Advisors which are Support
Escalation Engineers on reproducing this environment in Azure. Our
tests were configured using WS_FTP 7.7 (Your version 7.1) and WS_FTP
12 client as well as the Windows FTP client. The results of our
testing were the same as you are experiencing. We were able to log in
to the server, but we get the same Command Port/List failures.
As we discussed previously Active FTP uses a random port for the data
plane on the client side. The server connects via 21 and 20, but the
incoming port is a random ephemeral port. In Passive FTP, this can
be defined and therefore endpoints can be created for each port you
use for part of the data plane.
Based on our extensive testing yesterday I would not expect any other Active FTP solution to work. The escalation Engineer that
assisted yesterday also discussed this with other members of his team
and they have not seen any successful Active FTP deployments in Azure.
In conclusion, my initial thoughts have been confirmed with our
testing and Active FTP will not work in the Azure environment at
this time. We are always striving to improve Azure’s offering so
this may be something that will work in the future as we continue to
grow.
You will need to move to a passive FTP setup if you are going to host
this FTP server in Azure.
When using active ftp, the client initiates the connection to port 21 on the FTP server. This is the command or control channel and this connection usually succeeds. However, the FTP server then attempts to open port 20 on the client. This is the data channel. This channel is used for all data transfers, including directory listings.
So, in your case, active FTP isn't working because the server can't initiate a connection to the client. This is either a problem on the server (outbound firewall rule) or on the client itself. This is usually a good thing because you don't want internet-based servers to be able to open connections on client machines.
In passive mode there is a clear client/server distinction where the client initiates connections to the server. Passive mode is recommended so if you got that working I'd stick with that.
I don't know how to begin on the following. I will explain with the picture below what i want to do.
Like you so you have 2 parts. The local part and the azure part. The azure part is my part. The local network could be a customer, ....
What i went to do is running a service on the pc's and send that data to the local server/gateway. But how can i detect to what server it needs to connect. I don't install any service on the local pc's, that does the customer itself. But i don't want that he needs to do configuration. Just like they install the server/gateway part.
I will run a webservice on azure that gets information from the server/gateway on the local network. So thats no problem. On azure there are some other application that will process the messages.
Also how can you send some message back to the local network? When you say on azure ping the other local computer on the network. You should send a message to the server/gateway on your local network. But how?
So i have 2 questions(see above for more information):
Connecting from the clients to the server/gateway
Send some information back to the local netwerk
You can use Virtual Network, Azure Connect to create a "connection" or "hybrid cloud" between the PCs and the Azure cloud. However, if you are talking about web based/simple messaging and the PCs have internet connectivity why not just route the messages through a secure (SSL/TLS) connection to the cloud?
For broadcasting/push-type notifications, please look at SignalR (http://signalr.net/). Microsoft is making that part of the ASP.NET platform: http://channel9.msdn.com/Events/Build/2012/3-034
It has some real nice functionality like gracefully, falling back on multiple mechanisms if advanced things like WebSockets are not supported by the server/client. This is an ideal solution and super scalable, since it is server based and very light on the client.
If you need to connect only one or more services running on you local network and make them available publicly via azure cloud.
The most straight forward solution i found was to use the services bus. Its require nearly no modification to you business network.
I am new to TFS and trying to setup where remote users can access the Source Repository and Work Items without having a VPN to the local network.
Is this possible?
From what I've seen the answer is NO. The TFS Proxy component does NOT appear to be what is needed to allow remote access, but rather a way to improve speed for remote users as long as they have VPN connection.
So how can configure TFS with NO VPN requirement?
Thanks ...
The second problem is how will you authenticate them? If you can't VPN to the network, there will be lot's of issues with the Domain access to the TFS.
Home made solution is to create an machine in DMZ and open it via RDP to the remote users (it's not safe at all)