Anyways, whoever is interested to read it can go to his weblog and read it. Click here

Every system administrator knows what it means, and yes –
it gives us shivers, especially when we don’t have physical acess to the
machine, and we can’t log in.

There are (at least) two ways to solve the problem, the
easy one and the hard one, as usual.

The easy one – applies if TS runs on a Windows 2003
machine, and Console session is logged off but two active (or disconnected)
sessions block further access.

From the client machine, go to Start -> Run and
type

mstsc
-v:0.0.0.0 /f –console

Replace 0.0.0.0 with TS server’s IP.

After you log in, go to Terminal Server Management and
disconnect active, idle and other remote sessions. Logg of and then log on as
you would normally do.

The hard way – applies in cases when the easy way
fails (Windows 2000 runs as a TS server, Console session logged in, etc.)

Conditions to be met for the hard way to succeed:

 
  - telnet service must not be disabled on the TS machine, it must be set
to either automatic or manual
startup.
  - you must have the “netsvc.exe” tool from the windows 2000
resource kit if you need to start telnet on the terminal  services machine
if it is not running. If you don’t have it, you can download
it here.

Authenticate to the terminal server from the remote
machine with the “net use” command:

Start->Run->cmd

C:\>net use \\<ip
address>\admin$ /user:<admin username>  

Example:

C:\>net use
\\192.168.1.1\admin$ /user:paja

Use regedt32 to modify the registry entry to allow telnet
without NTLM.

Start->Run->regedt32

connect to the remote machine:

Registry->Select
Computer

in the “Computer” field, enter “\\<ip
address”

Set the following key
to 0:

\HKEY_LOCAL_MACHINE
on <ipaddress>\SOFTWARE\Microsoft \TelnetServer\1.0\NTLM

Use netsvc.exe to start telnet service (tlntsvr):

c:\>netsvc
tlntsvr \\<ip address> /start

From the telnet session, use the “logoff”
command with session IDs of “1″ and “2″ to end the
disconnected but active sessions:

C:\>logoff 1
C:\>logoff 2
C:\>exit

(Be patient. Logoff takes some time.)

Use netsvc.exe to stop the telnet service if you want:

C:\netsvc tlntsvr \\<ip address> /stop

notes from Vladimir Milovanovic’s blog

Included Files

With the theory behind us, let’s take a look at the files included in the download file. Note that I did not try to pretty it up or put a lot of error checking in it. It’s simple and easy to understand, but that also means that you may need to do some digging into the files to make any changes or to troubleshoot any issues that I didn’t handle in a friendly way.

[The first two files are the ones that you will use to do a Metabase Merge or Push.]

MetabasePush.bat

Usage: MetabasePush {ServerIP} [SMTP FQDN]

You can call this from a batch file that can live somewhere else, like on the desktop of your primary web server. It will do a metabase push from the current server (localhost) to the target server specified by the ServerIP.

You can optionally add the SMTP FQDN and it will update that on the target server. We use that at ORCS Web because each server node has a different SMTP FQDN.

MetabaseMerge.bat

Usage: MetabaseMerge {ServerIP} [SMTP FQDN]

This operates the same as MetabasePush except that it does a Merge instead. The ServerIP is required and the SMTP FQDN is optional. Don’t forget the differences mentioned above between a Push and Merge. This file calls RemoveAdminACLLine.vbs so that the target server retains its own security settings.

[The following files are helper files and don’t need to be run directly.]

IIsCnfg2.vbs

This is a copy (confirmed up to date May 2006) of IIsCnfg.vbs but with two minor modifications to make the target username and password optional.

Metaacl.vbs

This is an untouched Microsoft script to view and update the metabase ACLs permissions.

RemoveAdminACLline.vbs

This is used by MetabaseMerge.bat to remove the ACL lines so that the permissions on the target server are left untouched during a Merge.

ChangeSMTP-FQDN.vbs

This will change the fully qualified domain name of the SMTP server on the target server that you specify. It is used when there are different SMTP DNS names on each server.

Scott Forsyth’s IIS Clustering Utilities

Try this online tool to generate the machinekey and enjoy!

Cross domain proxy

This is one of the most common approaches. Your script calls your server, your server makes the call to the remote server and then returns the result back to the client. There are some definite advantages to this approach: you have more control over the entire lifecycle. You can parse the data from the remote server, do with it what you will before sending it back to the client. If anything fails along the way, you can handle it in your own way. And lastly, you can log all remote calls. WIth that you can track success, failure and popularity.

Cross domain JSON

For this to work, the remote server needs to be set up to handle this. It needs to accept an additional parameter: a callback function. Then, to make the remote request, you insert a new script tag into your page with which will allow you to specify a remote URL. The reponse back will load a JSON object as a parameter of the callback function you specified in the request. Yahoo, for example, has implemented this feature in their web services API’s. This is great because you can implement web service calls without ever needing a scripting language on your server. Check out Jason Levitt’s article, JSON and the Dynamic Script Tag, on XML.com for more information.

Cross domain using Flash

Flash, by default, is much like Ajax in that you cannot request data from a remote server. However, you can enable this capability by placing a special XML file on the remote server to accept requests from other domains. With JavaScript’s capability to interact with Flash, we can use Flash as a bridge for sending cross-domain requests. (XML.com has a nice write-up of this technique.) There are still some limitations to this technique, most of which seems to be limited to older versions of Flash. There’s also the issue with users having Flash installed and enabled.

Sub-domains are still cross domains

One point to note and it’s fairly subtle. Plenty of us have our sites running at www.example.com and at example.com. They both point to the very same place. To us, we see them as the same thing. But to an Ajax call, it’s considered cross domain. Therefore, if you have to make an Ajax call to the same server, don’t code the domain as part of the request; just use the path.

The Future

Some have already begun looking into establishing standards that could be implemented into future browsers, such as JSONRequest and ContextAgnosticXMLHttpRequest. JSONRequest seems the most promising but that could be because I prefer JSON over XML and see it as really gaining traction over the next couple years.

Here’s a sample:
 
DECLARE @sortColumn VARCHAR(255)
SELECT @sortColumn = ‘title’

SELECT * FROM asset
ORDER BY
CASE
WHEN @sortColumn = ‘title’ THEN title
WHEN @sortColumn = ’start_date’ THEN start_date
WHEN @sortColumn = ‘asset_id’ THEN asset_id
ELSE title
END

I’ve been intending to install Subversion for quite a while, but I kept putting it off, because it looked like a daunting task. But when I actually decided to go do it, it took me all of an hour and a half to get it installed and working. If somebody had just written down what I needed to do to set up Subversion on Windows, with a real server running as a real Windows service, then it probably would’ve only taken me ten minutes, and I would’ve done it weeks ago.

Here, then, is the Mere-Moments Guide to installing a Subversion server on Windows. (It may look a bit intimidating, but really, it’s not.)

Some quick notes on the Guide:

• These instructions assume you’re using Windows 2000 or XP. (You’d better be; the Subversion server won’t run on Win9x.)
• If you want to know more about Subversion than just how to install it, check out the free O’Reilly Subversion book online and the not-free Pragmatic Version Control using Subversion.
• For Subversion to do you much good, you’ll have to add a new "project" (essentially a directory) to your repository, to put files in. In these instructions, I’m assuming that your new project will be called monkey (because mine was).
• Feel free to skip steps and to play around; you’ll learn more that way, because things won’t work right and you’ll have to figure out why.

And now, on to the Guide.

1. Download everything
   1. Go to http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=91 and download the most recent svn-x.y.z-setup.exe. At the time of this writing, the latest version was svn-1.2.0-setup.exe.
   2. Go to http://dark.clansoft.dk/~mbn/svnservice/ and download SVNService.zip.
   3. Go to http://tortoisesvn.tigris.org/download.html and download the most recent installer. At the time of this writing, the latest version was TortoiseSVN-1.1.7-UNICODE_svn-1.1.4.msi. (It doesn’t have to be the exact same version as the svn installer you got in step 1. See the compatibility chart.)
2. Install the server and the command-line client
   1. Run svn-x.y.z-setup.exe and let it install stuff.
   2. Go to Control Panel > System, go to the Advanced tab, and click the "Environment Variables" button at the bottom. Click the "New" button (either one, but if you’re undecided, use the one under "System variables"), set "variable name" to SVN_EDITOR, and "variable value" to the path and filename of a text editor of your choice (e.g., C:\Windows\Notepad.exe). OK all the way out.
3. Create a repository and configure access
   1. Create a new directory somewhere out of the way; this is where your repository will live, but you’ll almost never actually open the files directly. I made a directory called svn_repos directly under my C:\Documents and Settings, just so it’d be out of the way.
   2. Open a command prompt and type: svnadmin create "C:\Documents and Settings\svn_repos"
   3. In Windows Explorer, browse to the C:\Documents and Settings\svn_repos\conf directory (which svnadmin just created for you), and edit a couple of config files:
      1. Open the svnserve.conf file in a text editor, and uncomment the [general], anon-access = read, auth-access = write, and password-db = passwd lines. Save.
      2. Open the passwd file in a text editor, uncomment the [users] line, and add the username and password you want to use when connecting to your subversion server. Save.
4. Start the server manually, and create a project
   1. In your command window, type: svnserve –daemon –root "C:\Documents and Settings\svn_repos"
   2. Open a second command window, and type svn mkdir svn://localhost/monkey
   3. You’ll see the text editor you specified in step II.2, with some text already in it. Type a comment, like "Created the monkey project", at the beginning of the file (before the line starting with "–"). Save the file and close the editor.
   4. If your Subversion login is the same as your Windows login, then type your password (the one you put in the passwd file) at the prompt, and hit Enter. If your Subversion login is different from your Windows login, then just hit ENTER at the password prompt, and Subversion will then ask for both your login and your password.
   5. Subversion should tell you that it "Committed revision 1." Congratulations! You just checked a change into Subversion. Throw yourself a party. (Yes, creating a directory is a revisioned change — you can go back and get the repository as of a time before that directory existed. This is novel stuff for folks like me who still use VSS at work.)
   6. It’s conventional to have /trunk, /branches, and /tags subdirectories for each project (your code goes into trunk, and the others are where you put, well, branches and tags). Go ahead and type svn mkdir svn://localhost/monkey/trunk (and notice that, after you enter a checkin comment, it doesn’t prompt you for your password again — it’s smart like that).
5. Start the server for real
   1. Go back to the command window that’s running svnserve. Hit Ctrl+C to stop it.
   2. Open the SVNService.zip that you downloaded earlier. Extract SVNService.exe into your Subversion bin directory (Program Files\Subversion\bin). Yes, it’s important that you put it in this directory; it has to be in the same place as svnserve.exe from the Subversion distribution.
   3. In a command prompt, type svnservice -install –daemon –root "C:\Documents and Settings\svn_repos"
   4. Go to Control Panel > Administrative Tools > Services, double-click the SVNService service, and change its startup type from "Manual" to "Automatic". Now Subversion will start every time you start Windows.
   5. Start the SVNService service (by selecting it in the Services list, and clicking the "play" toolbar button).
   6. Go back to a command prompt, and type svn ls svn://localhost/
      This will list all the files in the root of the repository. If all is well and you’ve got a real Subversion server running now, you should see: monkey/
6. Install TortoiseSVN
   Sure, you can get by with a command-line client, but TortoiseSVN is cool — it integrates Subversion into Windows Explorer. You get little overlay icons showing the status of each file (in sync, needs to be checked in, not yet in the repository, etc.), and you can do pretty much everything you need by right-clicking on files and folders.
   1. Run the TortoiseSVN installer you got back in part I.
   2. Create a monkey directory somewhere on your hard drive. Right-click somewhere in that folder and select "SVN Checkout…" Type svn://localhost/monkey/trunk/ for the repository URL and click OK.
   3. Create a file in that directory, any file. Right-click the file and select TortoiseSVN > Add. Notice the little plus-sign icon that appears.
      The file hasn’t actually been checked in yet — Subversion’s commits are both batched and atomic, so this new file, together with any other new files you added, any files you changed, any files you deleted, any files you renamed, any directories you added or deleted or renamed, will all show up on the server all at once, as a single revision and a single checkin, the next time you right-click and select "SVN Commit".
7. Make it run on the network
   Are you kidding? You’re already networked. Go to another computer on your LAN, install TortoiseSVN, and do an "SVN Checkout…". When you specify the repository URL, use the same URL you did before, but replace "localhost" with the actual name of the computer that’s running the Subversion service (so in my case, the repository URL is svn://marsupial/monkey/trunk/ — nice little menagerie, there).

And there ya go — Subversion up and running on Windows, in mere moments or less.

Corrections, questions, etc. on this document are, as always, welcome; just speak up in the comments. Now go forth and control your revisions.

Enterprise Library Configuration Tool

Once I create my website in Visual Studio 2005, I immediately open up the Enterprise Library Configuration Tool and use it to open the existing web.config file.  Using only the tool, I then add the logging application block configuration section to web.config, remove all the defaults, and replace them with a simple FlatFile TraceListener that catches all events as shown below:

The Logging Application Block has a Special Source, called All Events.  Hooking a TraceListener to this event guarantees you will receive all events not being filtered.  Since we have no filters, we get all events.  These events get logged to the FlatFile TraceListener, which points to a log file at the root of my website, called trace.log ( default name ).

Catching and Logging Unhandled ASP.NET Exceptions

To catch unhandled exceptions in ASP.NET 2.0, I need to do a couple of things.

First, I need to reference Microsoft.Practices.EnterpriseLibrary.Logging in my website.  When you reference this library, it will also pull over a couple of other assemblies, Common and ObjectBuilder, that it depends upon.

Second, I need to add a Global Application File ( Global.asax ) to the website and enter the following code into Application_Error:

<%@ Application Language="C#" %><%@ Import Namespace="Microsoft.Practices.                       EnterpriseLibrary.Logging" %>

<script runat="server">

    void Application_Error(object sender, EventArgs e)     {        Exception ex = Server.GetLastError().GetBaseException();

        string message = ex.Message +                         "\nSOURCE: " + ex.Source +                        "\nFORM: " + Request.Form.ToString() +                         "\nQUERYSTRING: " +                            Request.QueryString.ToString() +                        "\nTARGETSITE: " + ex.TargetSite +                        "\nSTACKTRACE: " + ex.StackTrace;

        Logger.Write(message);    }

</script>

Logger is the name of the facade in the Logging Application Block to log messages.  I grab the unhandled exception and send it out to be logged.  The application doesn’t know and doesn’t care where; it is oblivious as to the actual logging strategy.

Creating An Unhandled Exception

Let’s open up Default.aspx.cs file and make it throw an exception:

public partial class _Default : System.Web.UI.Page {    protected void Page_Load(object sender, EventArgs e)    {        int error = Int32.Parse("bbbbb");    }}

The above with throw a System.FormatException error which will be logged in the trace.log file when running the application:

Timestamp: 2/15/2006 9:23:30 PM
Message: Input string was not in a correct format…<Stack Trace>

Conclusion

In about 15 minutes, you can successfully log unhandled exceptions in your ASP.NET 2.0 websites using Enterprise Library 2.0 Logging Application Block.

Source:  David Hayden ( .NET Developer )