We're using windows 2008 R2 servers and we need to backup the file to the other server whenever a file gets uploaded.
Unfortunately, the client requires that there would be no file/directory sharing between servers via LAN so we are trying to do this via WCF calling another WCF. But now we're having problem calling the other WCF since they're hosted on SSL-secured website.
Calling the WCF via silverlight works.
Questions:
1) What might be causing the SSL/TLS error when the WCF calls the other but everything works fine for the silverlight calling the WCF?
code:
public FileUpload(FileUploadClass file)
{
// store locally
...
// call the other wcf
if (!fileIsExisting)
{
ServiceRefClient svcClient = new ServiceRefClient();
svcClient.FileUploadClass(file)
}
}
2) Any other way to backup the file to the other server securely apart from using WCF and Database (I'm trying database now but hopefully there is a prettier way to do this)? File/Directory/Drive sharing via local network is prohibited.
Can you give more details on the exact error? Meanwhile you may want to check:
Assuming Server B hosting the WCF File Backup service is using a self signed certificate, does server A which is calling Server B have the certificate imported in the appropiate certificate store?
Again an assumption: Check Server A´s application pool identity, does it have sufficient permissions to call Server B?
Since dealing with security issues are often tough and time consuming, I decided to store the file as binaries to the database and load it from the 2nd server instead.
Impersonation works but that's really more of bypassing the securities.
Related
I have a RavenDB IIS instance that is working just fine via the Silverlight interface. I am trying to connect to as an embedded client by targeting the web folder, but I keep getting an error saying that it cannot find a lucene DLL. Is this even possible?
No, that is not possible. In embedded mode, the EmbeddableDocumentStore actually contains the database instance. Only one can be spun up at a time. You cannot have multiple embedded clients using the same set of files.
If you have an instance running in IIS, then don't connect with embedded mode. Connect using the regular client and point at the URL of your server.
I have a chat application developed using WCF call back contract.This use netTcp binding for the client server communication.
Client is a Windows Forms application will be running in the client machine(XP or Windows8 machine)
This WCF service hosted as a windows service in the server machine.I am maintaining a Client Session list in the service, this will store the details about each client connected to the server, this list is static variable.
The work flow is, whenever a client connect to the server using the connect operation,client details will be added to the client session list,this session list will be used by the server to send message back to the client whenever its needed.
Everything works fine in the single server environment,Now I want to know how can I handle this in the load balancing scenario, that means I have two server machine,at a time one server will be active.if Server 1 is fail, Server 2 will be active. In this scenario, How can I manage my client sessions share between two servers and working as usual with out disturbing my clients?
One option is to use a Session State store provider, which will provide the session state for both instances of server service.
As MSDN states: http://msdn.microsoft.com/en-us/library/z414bbk9(v=vs.100).aspx
for Web farm configurations, it can be stored out of process using
either the ASP.NET State service or a Microsoft SQL Server database.
The ASP.NET state service is quite well documented http://msdn.microsoft.com/en-us/library/ms178581(v=vs.100).aspx
As for the database solution... well... you have to analyse the added overhead due to database access.
Also, if you are hosting the service using IIS, you could consider using Out-of-Process session state (http://technet.microsoft.com/en-us/library/cc754032%28v=ws.10%29.aspx).
These are just some ideas. You can look into other web farm synchronization techniques made available for Microsoft technologies.
Summary:
Does anybody know if there are known issues or configuration gotchas with an IIS service connecting to an Azure based service?
Scenario:
I currently have a scenario that requires me to host two web-services, one in Azure, and one on a server running IIS. The IIS hosted service (a WCF service) connects to the Azure hosted service (actually the Azure storage API) in order to fetch certain information. This information is manipulated and returned to the client.
Client -> IIS Service -> Azure Storage Service
Issue:
I'm running into issues with the IIS service connecting to the Azure Service. The hostname cannot be resolved. I'm using the Azure Storage client from my code, but have actually tried this using the azure API calls, and they also do not work from IIS. I captured the requests using Fiddler (on a different machine), they match the azure REST API calls, as expected. These requests, when made outside of IIS on the host machine execute properly. It is only when they are issued by the IIS service that they fail.
In my research other people have been running into this issue when there's a firewall problem, but since I can hit the service properly from the machine, that doesn't seem to fit the bill. My hunch is that there's a configuration issue I need to sort out in IIS, but I've failed to find anything useful with my searches.
Does anyone have any information on why this might be occuring (known bugs, gotchas etc)? Any workarounds? From a SOA perspective, this seems fairly critical to understand.
Any assitance anyone has would be helpful. Thank you.
Sounds like a proxy configuration issue. Check how your IIS server connected to Internet. If you are using some sort of proxy to get to Internet, that connection has to be configured correctly.
Specifically, if your proxy servers are Microsoft ISA server, or Microsoft Forefront TMG, then you need to check two things:
ISA server client or Forefront TMG client software is installed on the server
The account used by IIS application pool is domain user. ISA Server/TMG are designed to work only with user account, not service account. Alternative workaround for this limitation is using "defaultProxy" configuration in web.config, however it only wokrs for HTTP/HTTPS.
If you use different proxy server, then other issues might be involved, for example proxy might require authentication.
We have a system where we host a couple of WCF applications in IIS. Some of these applications have a bit of an extended start-up time taking a couple of seconds (more than a users would be happy to wait for). Once it's up and running, everything is snappy though, so it really is only the startup time.
The client also has a requirement to recycle the application pools every night.
Is there some way to wake all these services up so that the start-up time is not an issue for the first user of the system?
Initial thoughts where to write a windows service that would simply call a lightweight method on each service every x (configurable) minutes to keep the apps alive, but since we are in a load balanced environment, and the applications need specific host headers to be passed, we would always hit the load balance address which means there is no way for us to make sure that all services on all boxes in the cluster are actually started.
Since a single wcf application in IIS can only have a single host header, the only other way would be to setup a second iis web site pointing at the same application. I'm just not sure if that would do the trick since it would be in another host context.
another option could be to wright something like an extension to IIS (not sure if this is possible yet) that could call each of our services when IIS or the app pool actually starts up again. (Something that notices when the app pool has recycled but before the first user request.
Any ideas would be much appreciated.
Thanks
Gineer
Excellent. Thanks Dercsár.
After a quick Google, I found the following arcticle on the subject: Using the IIS Application Warm-Up Module
The limitations here are that this is only available on Windows 2008 R2 with IIS 7.5. Although our client is in the process of upgrading to Win 2K8R2, this may still be some time off.
Does anyone know of a solution that would work for Windows 2003 with IIS 6 or will we have to write something do make this work?
Gineer
For those of us running on a version of IIS before 7.5, we are in the process of testing the following solution...
As mentioned in the original post, the initial idea was to fire off a WebRequest from a service running on each machine to the local web sites (which host the WCF services), but this would be impossible, since they all make use of Host headers, and they all live in a Network load balanced farm.
We then thought that we could simply provide the custom host headers in the web request to the localhost.
Turns out you can not update the host header name in a WebRequest. It’s a Read only field.
Messing with a proxy class makes it work though.
See: http://social.msdn.microsoft.com/forums/en-US/netfxnetcom/thread/1b35c665-fe32-4433-8877-a62f2d400a8e/
And a short piece of my test code below in C#.
WebRequest req = WebRequest.Create("<Correct Host name>");
req.Proxy = new WebProxy("127.0.0.1");
StreamReader stream = new StreamReader(
req.GetResponse().GetResponseStream());
StringBuilder sb = new StringBuilder();
String LineString;
while ((LineString = stream.ReadLine()) != null)
{
if (LineString.Length > 0)
sb.Append(LineString);
}
stream.Close();
String response = sb.ToString();
This may not be what the proxy class was intended for, but it seems to work either way.
Gineer
Ps. No, you do not need to have any actual proxy server installed on the local host machine.
I have a Web application and a WCF service hosted on the same Windows 2003 development server. They each have their own IIS website node responding to drs.displayscreen.web and drs.displayscreen.service host headers respectively. The hosts file contains entries for both headers pointing back to 127.0.0.1. The web site has a service reference to drs.displayscreen.service.
Both applications work perfectly when their application pool uses the 'Network Service' account.
I need to perform some COM processing under the hood on the service so I want to run the applications under a customised identity. Both sites run on a new application pool.
When I change the application pool identity to use a new windows account created for the purpose, I get the following (inner) exception:
[EndpointNotFoundException: Could not connect to http://drs.displayscreen.service/Handler.svc. TCP error code 10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 192.168.98.2:8080. ]
192.168.98.2:8080 is the address of a DNS server that is no longer in use. It is not referenced anywhere in the solution. It is not referenced by ipconfig at all.
I have made sure that the new account is a member of IIS_WPG and I have run aspnet_regiis -ga . I have also given the account explicit permission to read the hosts file.
Why does the application attempt to use the defunct DNS server to resolve the temporary url (drs.displayscreen.service) instead of the hosts file entry? It has to be a permission of some sort because it does not have this problem when running under the network service account. Help!!
Well, it appears that the answer might involve a bug in the .Net framework. I found a blog posting that clued me in to the fact that the MS .Net implementation of SocketCache.GetSocket might cache invalid sockets and another one that suggests a workaround/hack in the form of an explicit don't-use-proxies configuration setting.
We don't actually use a proxy server in the environment where this problem cropped up but it appears that SocketCache.GetSocket is overridden or behaves differently when the don't-use-proxies setting is in place. Strangely, removing the setting causes the problem to come back so obviously the SocketCache is not repaired when a valid ip/hostname is discovered and successfully used. According to the author of the first post mentioned above, the bug does not exist in Mono. :)