Sebastian P.R. Gingter's questions

I already had this running once with an older server, but now I changed hardware and cannot get this running again (I'm more a dev than a admin). Here's my network setup:

Internet | DSL Router | SWITCH | SERVER

The DSL router also is the DHCP and DNS server for the internal network in the 192.168.178.x range. It has the .1, and configured to assign always the same IP to the server (.25). It is forwarding everything necessary for the VPN to the Server (Port 1723 and GRE Protocol 47).

To configure the VPN I installed the Network Policy and Access Services Role with the features Remote Access Services and Routing.

I could not use the wizard when enabling Routing and remote access, because when I selected the NIC connected to the internal network as the NIC for the incoming connections, it only offered both VMware virtual network interfaces as the interfaces that should point to the internal network. So I manually configured VPN and Routing.

Now in the event log I see the following warning:

Unable to contact a DHCP server. The Automatic Private IP Address
169.254.64.27 will be assigned to dial-in clients.
Clients may be unable to access resources on the network.

And this exactly is my problem. Whenever I connect to the VPN I get this address assigned, and cannot find other hosts on the network.

I already tried to manually set the DHCP server for the relay agent: Routing and Remote Access -> IPv4 -> DHCP Relay agent -> Properties and entered 192.168.178.1 as a DHCP server. This had no effect.

So this is the actual question:

What Do I have to configure so that incoming connections on the physical NIC get IP addresses from the DHCP server (DSL router) connected on the very same NIC of the server and so that also DNS requests for the internal network (i.e. 'dreambox.fritz.box' where fritz.box is the name of the dsl router) work from the VPN client?

I'm trying to configure my IIS 7.5 to allow specials chars in the url for ASP.NET. This is important to support wide-spread legacy url's on a new system.

Sample url: http://mydomain.com/FileWith%inTheName.html This would be encoded in the url and requested as http://mydomain.com/FileWith25%inTheName.html

This simply works, when creating a new web in IIS 7.5, placing a file with the percentage sign in the file name in the web root and pointing the browser to it.

This does not work, however, when the web site is an ASP.NET application. ASP.NET always returns a 400.0 - Bad Request error in the WindowsAuthentication module from the StaticFile handler, when pointing to that url. It however displays the requested url correctly and also resolves correctly to the correct physical file (the information from the field 'Physical Path' from the Server error page points to the physically available file).

There are hints on how to enable this, so I followed the instructions on these websites step by step:

• http://dirk.net/2008/06/09/ampersand-the-request-url-in-iis7/
• http://adorr.net/2010/01/configure-iis-to-accept-url-with-special-characters.html

The second one actually sums up the information from the first post and adds some more information about x64 systems (we're running x64) and on an additional web.config change for this. I tried all that, and still can't get this running from an asp.net web application. And yes: I rebooted after applying the registry changes.

So, what do I have to do in addition to the settings described in above posts, to support the legacy url's which contain percentage characters?

Additional info: Application Pool mode is integrated.

Push after some days. No idea anyone?

we're evaluating the usage of the msdeploy Web Deployment Agent Service for automatic deployments to our production servers.

One thing we can't find out about are potential security impacts.

For one thing, our web servers are of course secured (behind firewalls and load balancers) so only http(s) traffic is allowed from the outside.

Nevertheless, the web deployment agent runs integrated with IIS (the only thing facing outside), as it is accessible via http(s). So we fear that it could be potentially possible to gain access to the agent through the webs hosted on that IIS - and hereby gaining read and write access to all our webs.

How secure is msdeploy for usage in production environments?

Update: Production web server are running IIS7.

I have a headless windows server 2008 R2 running, and obviously I forgot to enable remote administration. Every attempt to connect via remote desktop, even with the administrator user, is currently rejected because remote desktop isn't licenced. Which is correct, because I don't need it on that mashine, just should be able to configure the system from time to time.

So I'm a bit lazy: I don't want to shut down the system, carry it over to some place with monitor and keyboard, change the configuration, shut it down again and carry it back.

Is there a way to remotely connect to the machine and activate the remote administration via network, so that I can connect again?