I have a self hosted wcf service with a startup task that runs
netsh http add urlacl url=https://+:{PORT}/{SERVICENAME} user=everyone listen=yes delegate=yes"
previously the service didn't have ssl, but the old http url reservation was still there (or was added by something else I'm not aware of).
So do I need to add a netsh remove to startup task?
EDIT:
I remove desktop-ed to the role to check if the reservation is there.
To make you understand better the scenario, when you deploy your application in cloud, you are running application in a virtual machine within virtualize environment. Your application will be running within a data center however the virtual machine will be hosted on a host machine which can be changed any time due to any particular reason. This is possible due to Guest OS or Host OS update, hardware failure, resources change requirement, and any other reason. Because of it you should not consider that your virtual machine will always be same, to be more specific it is "virtual".
You can never assume it will be the same, it often is, but if there were a hardware failure and your role were restarted within the data center elsewhere, it certainly wouldn't be. Any startup task would need to be idempotent.
Related
I have created a service (WCF) that acts as a backend for a DB. For now it does basic operations such as INSERT, SELECT etc. I have run it locally and now it is time to expose her to the internet and enter 'production'. Is there a best practice to doing so? Bear in mind this service will be hosted on a PC as a Windows Service (not IIS). This is the first time I am putting a Windows Service into production so I am hazy on the details but I think this is the main idea:
On the service: Check for 'rookie' errors such as SQL Injection. Set maximum message sizes to ones marginally higher than the largest message that should be transmitted by my service. Also upgrade self signed X.509 certificate to one issued by a CA. (Where does one store this certificate? Locally on the PC?)
On the PC: Fully patched software (OS etc) and windows firewall with a specific set of rules that allows traffic only on the ports being used (I suppose the safest way to do this is to use the windows tool Allow a program or feature through Windows Firewall ?). Furthermore an updated antivirus running.
On the Network: For the network router, port forward the respective ports being used (the base address is declared as http://localhost:8080 so I guess port 80 for HTTP and 443 for HTTPS? I am using message level Security.)
General precautions: Full message logging on the service to analyze traffic and potential attackers. Also run a Network intrusion detection system such as Snort so that I can sleep a bit better at night.
Am I missing anything obvious? Also should I be hosting in IIS, on security exchange someone said that I would be vulnerable to HTTP attacks if I did not put the code behind a web server. However I have not read this anywhere else
I've just installed XAMPP and just wondering what are the benefits of running Apache as a service?
One of the benefits is that when installed as a service is that you can limit the privileges (directories read/write access, network access, this means better security of course) of the account that runs it (the default is the LocalSystem account on Windows, you can find more about it here).
And as admin pointed out, you can also keep the service running without you being logged in all the time.
The benefits of a service in general (on Windows) :
It can automatic start at System Logon
Start and stop not related to a specific user session
Run in Background
Can run under a special account (LocalSystem, Network Service)
From Vista/Server 2008 onwards run in Session 0 (Isolation)
If you use apache only for developing purpose you can avoid to install it as service and run it when needed directly from your user session, in a production enviroment is highly recommended to install and run it as service ...
-Don't have to start it after each boot.
-If you log off the server continues running.
If you will use the server all the time, set it as a service... If not, just start it when you need it to keep the resourses free.
I have multiple content servers on different machines. I need to check the status of every server. I'm concerned about things like disk size, priority etc.
One solution that I'm using now is to install a Window Service on each machine which regularly checks the server but I have to manually install the service on each server.
Is there any way I can get the server information like disk space from a WCF service or using a windows application? I want to create a single watcher for my servers as I have to add servers sometimes.
Look at windows WMI you can make remote calls to machines so long as you have permissions to do so. You will only have to run one service on one server that can connect to the others.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa394582(v=vs.85).aspx
I've got a working WCF service and a working Delphi client. On a normal PC, they work nicely. On a VM that's "Bridged" they work nicely if I log onto the domain (but not if I logon locally to the VM as administrator). If the VM is NATed, the connection attempt times out.
I would love to hear people's thoughts on what could be making such a difference to whether the client can successfully connect to the WCF service. Bear in mind I'm connecting with basicHttpBinding with no security.
The service is setup to use System Account (interact with desktop is NOT checked), and it starts automatically. The service URI doesn't change, the port is open, and can be telnet'd to in all scenarios.
Any ideas or pointers?
Within the VM, open Internet Explorer and verify that you can view the WSDL of the WCF service. If you can't, then your issue is connectivity and has nothing to do with your Delphi code.
Group Policies and Enterprise Security solutions that swap certificates or require certificates to be registered (we're using a UTM called CyberRoam) make a difference.
Also when Virtual Machines join a domain, their ComputerNames are added to a list maintained by the Domain Controller. When the same Virtual Machine is "moved" or "copied", its ComputerName should be changed to avoid DNS resolution issues.
I'm not claiming this as the definitive answer, however it does explain the issues I noticed in this instance.
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. :)