Does anyone recognise this error?
The SecurityContextSecurityToken with context-id=urn:uuid:xxx (key generation-id=) is not registered
It has suddenly appeared in the service trace log of my WCF service.
We had a Windows service successfully transmitting data into the WCF service for a day until it broke. The error manifests when the Windows service tries to connect to the WCF service.
It's highly unlikely that the environments changed. The two services exist on separate machines (an application server and a web server). Both are Windows Server 2003 SP1 machines, and the web server is running IIS 6.
Unfortunately, we have scarce access to the servers to help us debug, so any guesses on what might be wrong would be highly appreciated.
Indi
We had this problem with Web Service Extension 3.0, which was used before WCF. I have not experianced this with WCF, but I think that it is worth checking.
The scenario works like this:
The service starts and the user that is the identity of the service gets logged on.
When the service makes a call it is done in the security context of this user
After a while the logon token becomes so old (a day?) that the service will no longer accept it.
The easy way to test this is to restart the windows service.
Related
Here is a question for WCF hosting environment:
You are developing an application that performs file backups in the
background. The background application will host a Windows
Communication Foundation (WCF) service and must be active as soon as
the machine is running. The background application will not have a
user interface. A front-end application will consume the WCF service
and will provide the user interface.
You need to choose a host environment for the WCF service. Which
hosting environment should you choose?
A. Microsoft Internet Information Services (IIS) 6.0
B. Windows Process Activation Services (WAS)
C. A Windows Forms application
D. A Windows Service
The answer is D, but a lot documents of WCF MSDN and books all favor IIS/WAS over Windows Service, as they are more robust and resilient etc. I don't really see why it has to be D here. What is the reasoning behind D then?
The answer is D, because one of the requirements is:
must be active as soon as the machine is running.
When you use Windows Service you can start it even before user has authorized in system.
IIS gives on-demand loading. When a request comes in, the ServiceHost is constructed, then the service class being hosted is instantiated, and the request is handled. Nothing needs to be running around the clock. This setup requires more time and effort every time a message comes in.
On 1st server, there is wcf service hosted in windows managed service. On the 2nd server, there is another wcf service, hosted in their own windows managed service. I try to connect to 1st service from the inside of the 2nd service, but I become a exception "The socket connection was aborted". With same configuration and same code I successfully connect from console application and winform application, but not from this windows managed service.
Configure your WCF services on both servers to perform diagnostic logging. Follow the instructions in http://msdn.microsoft.com/en-us/library/ms730064.aspx to achieve that.
Make sure the account your service on server 2 is running under is capable of connecting to server 1. This is a typical difference between the client test you did (and worked) and a service running on that system. For a test, make the service on server 2 run under your personal login credentials.
My head hurts so much I think I need a bottle of aspirin...
I've created a WCF service and, with help of others from this site and the department I work in, the WCF service is running as a service on my development machine. Tested it with a console app and it works.
But, it's not supposed to be on my development machine. It needs to be on a different server.
This is difficult because the server it is supposed to reside on DOES NOT have Visual Studio installed on it.
So I cannot run the VS 2008 Command Prompt with installutil to run the WCF service as a service on that server.
Broadly speaking, you've got three options, all of which are described on MSDN:
Host the service under IIS
Self-host the service in any managed .NET application
Host the WCF service under a Windows Service
Which one is right for you depends on what your service is for, how it'll be consumed, how scalable and secure you need the set-up to be, and a dozen other things besides. Without knowing a bit more about what your service does and how it'll be used in your organisation, it's difficult to make a recommendation.
IIS hosting is easy to set up and is the way to go if you want to leverage all of the industrial-strength hosting functionality that a full-blown web server offers.
Self-hosting is quick and easy - you can knock out a WCF-hosting console app in two minutes flat - but is the clunky solution. You of course have to run the host application as a particular Windows user. Perhaps not ideal?
Hosting under a Windows service is the middle ground. It gives you that always-available functionality without having to be logged in as a specific user, but doesn't offer the configurability and scalability of the IIS solution. It takes a bit more effort than belting out a quick console app, but not much.
The server that the windows service will reside on will have the .NET Framework. INSTALLUTIL is located in the Microsoft.NET\Framework(version number) folder in the Windows directory.
For example, C:\Windows\Microsoft.NET\Framework\v2.0.50727.
No need to write a console app to host your service now (unless you want to).
You can also host your WCF service under IIS, check this out: MSDN - How to: Host a WCF Service in IIS. It really is just a five minute job :)
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.
I need to remotely spawn WCF services on a remote machine from a client. I cannot use IIS (no HTTP) or WAS (no Windows Server 2008).
Was wondering if there's a way to do it apart from these hosting environments without having to create a service on the remote machine responsible for the spawning of other WCF services.
If a Windows Service host is the only way, can someone point me to a good article or book for an efficient architecture for doing this (including lifecycle management of spawned WCF services).
Thanks
Riko
If you cannot use IIS/WAS, then you're only option left is self-hosting.
You can host your WCF service in either a Windows (NT) Service, or a console app, or any other app you like to have.
The point though is: other than IIS/WAS which will load your service class as needed, when a request comes in and needs to be processed, in a self-hosting environment, you have to have your host app up and running - that's why a NT Service seems like the best choice at least for production environments, a service that can be run even if no one is logged on to the machine. Console or other apps require a user being logged on, and the app must be running.
Hope this helps a bit.
Marc
There is one additional option you can use on Server 2003 - hosting WCF services in COM+:
http://msdn.microsoft.com/en-us/library/bb735856.aspx
This is not as easy as hosting non-HTTP services in WAS on Server 2008, but provides a better supported monitoring and deployment model than hosting as an NT Service. Generally in my experience, though, most people I know have used NT services since is fairly straightforward to generate one in .NET, and then they perf counters or something similar to monitor them in production.