I get following error, when I try to deploy a web app to IIS server using MSDeploy. I believe the cause of the issue is the size of the file. The file, which cause the problem, is the biggest file in the package with size 8M. May I know how to deal with it?
We had this same error a while back and it was a network issue. Pulled in our Network Operations team and they ran a diagnostic test and found the issue. Not sure what it was but I bet this is the same.
The issue was caused by firewall rules. Our network team found the traffic from the deployment server to IIS server was treated as an attack by firewall, then lock the traffic. After they make an exception between those two servers, the issue be resolved. Thanks again Chief7
Related
I've been handed a Genexus KB to make an SD app for it. But each time i want to try it i get a "an error occurred in the application server (Not found)" each time i've ran it in a real device (connected in the internal network thorugh) or in an Android Emulator (Andy).
I've setted the KB to point to a local DB stored in my computer and i've tried different ways to try it and it keeps with no luck.
What else should I do?
PS: when i run the web version of it, there's no problem.
Altight people, first of all thanks for the help you gave me!
Secondly #fpanizza that link you gave me was very useful, I could use CatLog with android emulator Andy (after installing Andy Rootkit) and I found out that my app wasn't reaching REST services in the server which leads me to #Franklin, who was right to let me know that it had to do with REST services and I've found out later that i didn't had installed HTTP Activation at one of the WCF Services at the .Net Framework 4.5 Advanced Services, which allowed to reach REST services, and now it worked.
You can try setting the server URL with the IP of your server.
Is probable that the local host is trying to access itself, the android device.
Service URL property: http://wiki.genexus.com/commwiki/servlet/hwikibypageid?21146
Update
I would do what fpanizza suggests on the comment.
Another troubleshooting idea that may bring some light into problem would be to try to access the rest services from a web navigator on the emulator. The idea would be to validate that the emulator/device can "see" the server. Testing outside the app will help understand if the problem is in the app or the server or the connection device - server.
Thank you #Juan.
For better understanding here I enclose the image.
Control Panel > All Control Panel Items > Programs and Features > Turn Windows features on or off
I am writing a webdav server for embedded system. Everything goes normal until I tested it with windows client, the miniredir.
It became extremely slow when accessing the data with miniredir. I captured the network traffic and found that everytime I made a move, the miniredir tried to connect to the server via SMB first. (SYN package sent to 137,138,139,445) and the expolrer view would not show until the SMB request failed a few times, which takes more than 20s.
I also tried miniredir with Apache+mod_dav, same delay was observed (make sure the server machine disabled SMB service).
Is there anyone solved this problem? or if there's any work around solution for XP?
BTW: After a few days' debugging, now I believe MS Miniredir is not a qualified WebDAV client. A lot of bugs and shorting comings were reported, but MS didn't do much improvement. http://www.greenbytes.de/tech/webdav/webdav-redirector-list.html
Significant delays can be encountered when accessing WebDAV resources if Internet Explorer is configured to auto-detect proxy servers. Try following these instructions for disabling proxy auto-detection and see if that helps.
After a few days' debugging, now I believe MS Miniredir is not a qualified WebDAV client.
I think this is an overstatement. The only documented issue in XP/SP3 is a by-default lack of support for basic auth, and there is a workaround for this. "When you hear hoofbeats, look for horses, not zebras."
I am at my wits' end on this one.
FYI, I work in infrastructure, not .net development, so I know very little about WCF and next to nothing about Visual Studio as an environment, but I don't think that's where the problem lies.
We have a WCF service running on a couple of IIS 7.5 servers on our internal network. This is exposed to the outside world via reverse proxy on Apache 2.2.15 on Fedora 11. The reverse proxy handles load balancing between the IIS servers, as well as SSL.
The WCF service is configured to use transport level security, and the IIS servers have self-signed SSL certificates. The reverse proxy does not authenticate the IIS servers, and the only reason we have SSL on the IIS servers in the first place is so the WSDL will present the correct location URL.
We thought we had it working perfectly, but there's one annoying and crucial exception: the WSDL can't be added as a service reference in Visual Studio on machines running Windows Vista or later. On an XP machine, it's fine, but anything later throws the following error:
There was an error downloading
'[URL]'. The operation has timed out
Metadata contains a reference that
cannot be resolved: '[URL]'. An error
occurred while making the HTTP request
to [URL]. This could be due to the
fact that the server certificate is
not configured properly with HTTP.SYS
in the HTTPS case. This could also be
caused by a mismatch of the security
binding between the client and the
server. The underlying connection was
closed: An unexpected error occurred
on a send. Received an unexpected EOF
or 0 bytes from the transport stream.
If the service is defined in the
current solution, try building the
solution and adding the service
reference again.
The WSDL is accessible through a browser, or through regular SOAP, on any machine and without any SSL complaints. It's just Visual Studio that has an issue.
Initial Googling revealed that it might be a problem with the cipher suite that VS used, suggesting that VS on Vista or later would by default attempt to use TLS1.0 in HTTPS connections, and if an intermediary device didn't support that protocol, it would just drop the request. This is definitely not the case, though. The reverse proxy explicitly prefers TLS1.0, and even when viewing the WSDL through a browser, it flags up as using TLS1.0 for the connection.
Having pointed the proxy at other functioning WCF services on different IIS servers, the same error occurs, leading me to assume it revolves around the reverse proxy configuration. The trouble is that it seems to be identically configured to another reverse proxy carrying out the same task elsewhere.
It's presumably some transport level issue around how VS establishes HTTPS connections on different operating systems, but I simply don't know enough about it to hazard a guess about what that might be. Anyone have any suggestions?
Well, that was embarrassing.
I'm sure there's some unwritten cosmic law that results in me finding the incredibly simple solution to a problem I've been grinding away at for days about ten minutes after posting it up on StackOverflow.
The ServerName directive in the virtual host config didn't match the URL. It did match the certificate (which has a Subject Alternative Name, so it didn't throw up any SSL warnings), but that wasn't the name I was accessing it with.
I'm assuming there's some extension of TLS1.0 that VS uses which enforces this, which isn't used by browsers or SOAP clients. This is probably useful information for anyone else trying this with a certificate that has Subject Alternative Names. It wouldn't have come up otherwise.
I'm remote debugging a console app which has some AD functionality.
When I run it on the remote server it works like a charm. (I mean I log in with RDC and literally double click the console app .exe file.)
While remote debugging however, I'm getting an error in the AD related code - "Could not find the domain or the domain does not exist".
Important to note is my dev machine is not on the same domain as remote server. I'm also remote debugging over VPN.
I also want to mention that otherwise the remote debugging seems to be working ok, breakpoints are being met, symbols loading, values populating.
The full source code is kinda long, so I'll just provide an illustation of what is causing the problem:
System.DirectoryServices.DirectoryEntry dirEntry; // in reality this is setup via an ad helper class
dirEntry.rootOU.Children.Find(strOU, "Something"); // BOOM! here is where it can't find the domain
Its not a code issue, and the domain does genuinely exist and is reachable, when code is natively executed on the server, issue only comes in with remote debugging.
Thanks in advance for suggestions on a fix / cause.
After hours of struggling, I found the problem but no solution.
The solution is to have your environments setup in best case scenario if you want to remote debug in an SOA application, connecting to many systems using domain accounts etc.
Your local dev environment should be running under the same domain and account as the account running the remote services on the server. Furthermore, this account needs to have correct permissions in your SOA systems. I.E: If you're working with AD, this account needs to have required permissions. If you're working with Sharepoint, you might need to use the farm admin account. SQL or Databases are much more forgiving because you can configure connection strings.
If you fail to do any of the above, remote debugging can still work for you but it might not. If it does not, what I've found is there is no work around.
You might think you would be able to use No authentication remote debugging, but that does not work with managed code. So (Jan 28th 2010) no solution exists.
I hope this is addressed in the future, because it can be extremely convenient debug remotely.
I've installed TFS 2008, but I can't seem to access the server. When I try to connect to it in Visual Studio, I can't. If I try by browser on a remote PC, I get a generic page cannot be displayed. On the server, I get a 403. Nothing was touched in IIS and the service is running as a Network Service. Any ideas?
try:
http://localhost:8080/Services/V1.0/ServerStatus.asmx. This will tell you if TFS is up and running. If you are getting anything else you need to look into IIS issues.
I wrote a blog post on diagnosing these types of TFS connections.
http://blogs.msdn.com/granth/archive/2008/06/26/troubleshooting-connections-to-tfs.aspx
The very first thing I do is confirm that it works for a known-good configuration – usually my workstation.
Providing that works and the server appears to be functioning, the next thing I do is ask the user to call the CheckAuthentication web service using Internet Explorer.
The URL for this is: http://TFSSERVER:8080/services/v1.0/ServerStatus.asmx?op=CheckAuthentication
By doing this check, I am doing four things:
Eliminating Team Explorer from the picture
Eliminating the .NET networking stack from the picture
Ensuring that Windows Authentication is working correctly (that’s why I say IE)
Ensuring that proxy settings are set correctly
In most cases I’ve seen, the TFS connection issues are because the proxy settings have changed or are incorrect. Because .NET and Visual Studio use the proxy settings from Internet Explorer, it’s important to have them set correctly.
In rare cases it’s beyond this. That’s when I start looking at things like:
Can you resolve the server name?
Can you connect using the IP address?
Are there HOSTS file entries? (see: c:\windows\system32\drivers\etc\hosts)
Can you ping the server?
Can you telnet to port 8080?
Does the user actually have access? Run TfsSecurity.exe /server:servername /im n:DOMAIN\User to check their group memberships
Have you changed your domain password lately? In some cases they’ll need to logoff the workstation and log back on again to get a new security token.
Is the computer's domain certificate valid? update the certificate: gpupdate /force
Hope this helps.
Turns out the time and date on my computer was not "close enough" to the time and date on the tfs server. Changed my system clock setting and problem went away.
What happens if you send a simple HTTP request to the server directly?
ie:
telnet 8080 [enter]
GET / HTTP/1.1[enter]
[enter]
[enter]
That might give a hint about whether IIS is actually serving anything. If you can do that on the server, what about from a different machine? If the results are different a good guess is there are some security/firewall issues somewhere. HTH a little.
I went through everything on a similar problem.
I logged onto my tfs server and connected directly there.
I also used a TFS admin tool I downloaded some time ago from Microsoft, and made sure I was in all the right groups and projects.
I then went back to the client PC with the problem, tried the services/1.0/serverstatus.asmx?op=CheckAuthentication Url again, and it worked this time.
AFter that full service was restored to my PC.
So I don't have the exact answer, but I would go through the checklists presented by Grant Holliday in his answer.
Add this to the cases for future users, as i had this issue on server 2016...
if your firewall allow only Domain and Private Network, it may not work on client. make sure you give public permission, if server network is set to public...
The error you may face:
ERR_CONNECTION_TIMED_OUT
for
http://fserver:8080/tfs