Tuesday, March 21, 2006

How to change IIS 6.0 Configurations by editing Metabase.xml

There are many settings in IIS. Starting from version 6.0, the settings are stored in a text file called metabase.xml under %SystemRoot%\System32\Inetsrv. If you configure the IIS server such that directly editing this file is allowed, you can make changes of the behaviors of the IIS server by just changing the values in this XML file.
For example, there is a 4 MB limitation on Response Buffer. That is, is you try to use Response.BinaryWrite to download contents to the user, 4 MB is the default maximum you can reach. However, if you change the value ASPBufferingLimit in metabase.xml, you can make the value suitable for your system.
Please note this Buffering limitation is different from the file upload limitation we mentioned in one of the earlier articles, which is controlled by maxRequestLength in Web.Config.
For details, please refer to: http://www.windowsdevcenter.com/pub/a/windows/2004/07/13/iis_metabase.html

How to Debug Local VBS (VBScript) files and JS files

It is well known that VBScript (and JavaScript) can be used in ASP pages for Web Applications, and it is also known that vbs files (and js files) can run locally under WSH (Windows Script Hosting) in Microsoft Windows environment. The command line to run vbs, say foo.vbs, locally is:
WScript.exe foo.vbs
You can just doubleclick foo.vbs in Windows Explorer to run it too. WScript.exe runs foo.vbs under Windows Graphical Environment. In many IT tasks, we prefer command line (DOS) interface, so we put vbs in batch files. For command line execution, where the input and output are to and from DOS box, we type:
CScript.exe foo.vbs.
To create/edit vbs (and js), we can just use a simple editor, like Notepad, or your preferred editor. To debug, we either put the whole file into VB6 development environment, modify some lines to be suitable for VB6 syntax, and debug there. Once debugged, we change the syntax back to VBScript and use it in production. If we can’t afford to buy VB6, we can just use "MsgBox" ("printf") way. NO matter we are using VB6 or MsgBox approach, the debug process is not productive at all.
Microsoft does provide the debugging environment for vbs and js file, but the way to invoke it is a kind of tricky. To debug foo.vbs, the command line is:
WScript.exe //D //X foo.vbs
Right after you type this, the system tells you a run-time exception happened, do you want to debug ? You say Yes.
If you have Visual Studio Visual Interdev installed, the system will invoke the Visual Interdev debugger, mdm.exe, for you. This is preferred, as the function is rich, and the UI is exactly like debugging under ASP environment.
If you do not have Visual Studio Visual Interdev installed, the system will check if you have Microsoft Script Debugger installed. If yes, it will invoke this debugger MSScrDBG.exe. This debug is less convenient than the previous one, and the debug command set are different from the Visual Interdev one.
If you don’t have Microsoft Script Debugger installed, you can download it from:
http://www.microsoft.com/downloads/details.aspx?FamilyID=2f465be0-94fd-4569-b3c4-dffdf19ccd99&displaylang=en
For more information:
http://support.microsoft.com/default.aspx?scid=kb;en-us;308364

Overcome ASP.NET upload size limitation

The default size limitation in ASP.NET is 4MB. To overcome that size, you will need to add the following under System.Web section of either the Machine.Config file (to make it system wide), or Web.Config file (to make it application wide) :executionTimeout="90"maxRequestLength="4096"useFullyQualifiedRedirectUrl="false"minFreeThreads="8"minLocalRequestFreeThreads="4"appRequestQueueLimit="100" />Please note that the highlighted ones are must, in order to increase the upload file size limitation.The values in the example are default value. You should make it larger.http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/aspnet-fileupload.asp

Terminal Service IP Filtering on Windows Server 2000/2003

Unlike Internet Information Services (IIS),Windows Terminal Services does not have a place in the admin/config functions to Filter the IP’s such that it can only allow certain IP’s to login to the Services. This is a problem, because it opens the door for any hackers from the world to use TCP port 3389 to try to login. Even if they fail, they may have locked out many accounts when the legitimate users triy to login in.
As a matter of fact, starting from Windows Server 2000, Windows has a central place to accept or block IP traffic. It is under Administrative Tools -> Local Security Policy -> IP Security Policy. By default, all traffic inbound/outboard of any protocol for any ports are accepted.
To limit IPs to Terminal Service (TCP port 3389), or any other services like SQL Server Services, SNMP, SMTP, etc, we will need to create a Policy and activate it. A Policy contains pairs of (IP List + Actions). One the policy is set and activated, only IP’s not permitted will be allowed. For example, if we only allow IP Block 160.203.229.0/24 to access this Terminal Service, we should create an entry with this IP block and the action "Permit". After that, we should add another entry to "Deny" Any IP addresses. With these two entries in this policy, when it is activated, it will only allow this IP block 160.203.229.0/24 to access the Terminal Service. We can add more IP blocks if needed.
For step by step instructions for Windows 2000 Server, please refer to:
http://www.securityfocus.com/infocus/1559
Set up IP Security Policy for Windows 2003 Server is very similar.

Calling Web Services from within Notes/Domino Database

IBM Claims that Domino/Notes designers, starting from version 5.07a, can call SOAP based Web Service from within the Notes/Domino System. This is the claim. But if we look deeper into the implementation, it is messy and awkward.
The document can be found here:
http://www-128.ibm.com/developerworks/webservices/library/ws-soapcon/
In brief, the designer will need to download a connector called SoapConnect for LotusScript (Can be found in the link above) to help to connect to the SOAP service. Since the connector is written in Java, so even if you don’t use Java to develop Notes code, you still need to install a specific version of Java Run-time to get it work.
The sample LotusScript code is like:
1 %INCLUDE "SoapConnect"
2 Dim session As New NotesSession
3 Dim doc As NotesDocument
4 Dim myArgs(0) As Variant
5 Dim price As String
6 Set doc = session.DocumentContext
7 Dim bn As New SOAPClient("http://services.xmethods.com:80/soap/servlet/rpcrouter" )
8 myArgs( 0 ) = doc.BookNumber( 0 )
9 price = bn.invoke("urn:xmethods-BNPriceCheck", "getPrice", myArgs)

Writing the code may be simple, but setting up the run time environment can be tricky. Since Domino has made version 7 an easy platform to implement web service client and server, it is unlikely they will support version 5/6 much on Web Services any more. So I don’t expect it to be an easy task.

Integrate IBM Notes with Microsoft.NET

To integrate Notes and .NET, IBM, Microsoft and the 3rd party all provide solutions.
IBM’s Redbook web site (http://www.redbooks.ibm.com/redpapers/pdfs/redp3868.pdf#search=’IBM%20Notes%2FDomino%20.NET’) tells us to integrate Notes through ActiveX/COM, Web Service and .NET approach with the outside world. In most cases, we want Notes database to be accessed with Active/COM, Web Service, or .NET Assembly. In other words, we want consume Notes information from the outside world, or BizNET world.
Microsoft also has a web site, http://www.msdomino.net/, to provide links of the solutions. It looks unofficial, but it has tons of demo projects and sample codes. The approaches are clearly VS.NET oriented, instead of Notes Oriented in IBM’s web Site. It can be easier, and more familiar for us to implement.
Proposition, Inc., also provide the so called N2N solution: http://www.proposion.com/site/proposion.nsf/pages/N2N, to integrate Notes with NET. It provide middle ware to make the integration easier, but it is fee based. The Server Run-Time license starts from $1595.

Create Web Reference DLL by using .NET Framework and Command Line

It is easy to create web reference by using VS.NET, just browse the Web Service URL and give it a namespace. But if you do not VS.NET, you will have to do that manually.
First of all, you will need to run wsdl.exe to generate the proxy code in the language you want. So if you do:
wsdl http://www.mysite.com/Web%20Service%20Agent.nsf/DominoDotNetWSDL /l:vb /n /out:DomService.vb /namespace:com.mysite.www
You are generating the proxy code in vb, the file name is DOMService.vb, and the namespace is com.mysite.www.
Please note that if you write this in a batch file, you will need to double ’%’ when you need to write a single ’%’, that is because batch file always thinks a number after a single ’%’ is a parameter name supplied by the command line. But if you double ’%’ to make it ’%%’, it will believe you really mean a single ’%’.
For example, if you put the above command line in a batch file and run, it will fail because the batch file thinks the URL is actually http://www.mysite.com/Web0Service0Agent.nsf/DominoDotNetWSDL. Please note that both instances of ’%2’ disappeared, as you did not supply parameter(s) in the batch file command line.
So in order not to confuse batch file, we will need to make the command line like:
wsdl http://www.mysite.com/Web%%20Service%%20Agent.nsf/DominoDotNetWSDL /l:vb /n /out:DomService.vb /namespace:com.mysite.www
After DOMService.vb is generated, you can either put that directly into your EXE build batch file to consume this Web Service, or ’wrap’ this Web Service into a DLL for other .NET EXE to consume. Let’s say we want to do the 2nd approach:
vbc /t:library /out:MyDOMService.dll Domservice.vb /r:System.dll,System.XML.dll,System.Web.Services.dll
This will build the DLL which provides Web Services.
vbc /t:winexe Form1.vb /out:FormVB1.EXE /r:System.dll,System.XML.dll,System.Web.Services.dll,System.Drawing.dll,System.Windows.Forms.dll,MyDomService.dll /main:Form1
This will build a application FormVB1.EXE using this Web Service DLL.

How to move IIS 5.0/6.0 Web Server Configurations to another Server

There are times we will need to move/merge IISI Web Server/Services to another machine. Copying files are easy, but copying configurations are not, as they are stored in the Windows NT Metabase.
There are tools for Windows 2000 Servers and Windows 2003 Servers to Sync, Backup, and Restore Web Configurations. These tools are the vbs files stored in %SystemRoot%\system32\inetsrv subfolders, or %SystemRoot%\System32 sub-folders.
For Windows 2000 Server, or IIS 5.0, %systemroot%\system32\inetsrv\iissync.exe will do the job. The command is: iissync computername. Where computername is the computer you want to move the configurations to.
For Windows 2003 Server, or iis 6.0, You have more options to do the more complicated task like merge metabase, etc. But the simplest one is to backup the metabase from the old, , copy the backed up files to the new, and restore the metabase to the new.
To backup the configurations, go to %systemroot%\system32, then do: iisback /backup.
This will backup the metabase to a file called SampleBackup under %systemroot%\system32\inetsrv\MetaBack. The file name are called SampleBackup.md0 and SampleBackup.sc0. For more options, type iisback /backup /?
Now, before you restore, you will need to move all these SampleBackup files to the new machine, and put them into the sample place. Once they are there, you do:
iisback /restore /b SampleBackup
This should do. for more options, please use iisback /restore /?
This is the easiest and the fastest, but since it is just a complete metabase copy from the source to the destination, you’d better edit the backed up SampleBackup files, to change the machine names at least, before you restore.
There are more sophisticated ones to merge two or more metabases together. The command line is called iiscnfg.vbs. It is also located under %systemroot%\system32.