A non-tech's guide to installing (IIS hosted) PortWeb

Version 4 of Portfolio had separate serial codes for the client, server. This changed as of Version 5.0. If you are using PortWeb that came with your Portfolio 5 (Network) or v6.x then you don't need a serial code or any additional licensing as it comes free with the product.

However, you should note the following, especially if your PortWeb installation is hosted externally;

1. Ensure that your (ISP's) server is running Microsoft IIS. PortWeb won't work with Apache or any Unix web servers - as yet.
2. Ensure that the Scripts folder has 'Scripts and Executables' under the 'Execute' permissions. In a hosted situation this is something that your ISP may have to do at their end.
3. If the ISP is running NT 4 or Windows 2000 Server they need to ensure that the IUSR_computername user has been given full access rights to the Scripts folder's Security properties. This is definitely something that can only be done on the ISP's end. The 'Modify' permission is needed - not just 'Write'.
4. Portfolio, (Portfolio Server) and PortWeb all have to be exactly the same version in order to successfully enable Portfolio Catalogues to be served. To make this clearer, if you were running version 5.0.1 of Portfolio client and had PortWeb version 5.0 installed, you will not be able to enable the catalogue on PortWeb Admin.
5. The relative location of the PortWeb.dll and the Catalogues & images is immaterial as long as the permissions are set up to allow PortWeb to 'see' (i.e. access) the target files. Put in tech terms, the IUSR_computername IIS account needs to have NTFS read permissions for any files it wishes to access.
6. PortWeb does not require an installer. The DLL is a CGI app so you do not need to register it as you might an ActiveX.DLL, it just needs to have IIS execute permissions for the IUSR_computername account. So you can send the PortWeb.DLL to the ISP or their staff can install the files locally. They only need to copy over the PortWeb.dll file into the Scripts folder. If they've also mistakenly copied over anything like PortWeb.ini, PortWeb.adm and PortWeb.wdb from another installation it's best that they remove these files and restart the web server (the World Wide Web Publishing service, that is - not just the Web site).
7. Is there a specific location where PortWeb.dll should be put? The DLL can be put in a Virtual directory (i.e. just about anywhere on the server). It all comes down to how the DLL is called from the client's web browser, so the appropriate execute permissions and directory structure need to be accounted for. The NTFS permissions are the most important part.
8. Can you install multiple copies of PortWeb.dll on the same machine (since many web servers run multiple websites)? Yes, you can have multiple copies of the PortWeb.dll but the first PortWeb.ini file read loads global values that are used by any subsequent PortWeb.dll CGI instance. This is a design flaw and not fixed to date (v5.01).
9. The Catalogue(s) should be set up for use via the PortWeb adminshow interface but alternatively you can directly edit the PortWeb.ini file located in the same directory as the PortWeb.dll but also note item 8 above. To 'unserve' a Catalogue via editing either delete the Catalogue's entry or 'rem' it out by placing a semi-colon a the start of the line. By commenting out a line, it will show up in the adminshow page listing but without a tick in the 'enabled' box. After such editing you should restart the web server (the World Wide Web Publishing service, that is - not just the Web site).
10. Is read-only access to Catalogue & assets sufficient? Read-only permissions for the appropriate user account (IUSR_computername). This is a much longer discussion and is where 95% of the problems are likely to occur. Have the administrator open the permissions to everyone and then incrementally tighten security until they break it. That's the best way to figure out what is causing the problem. The shopping cart feature (Collections) uses server side cookies in certain scenarios and needs special write access to the PortWeb.adm and PortWeb.wdb files (located in the PortWeb.dll directory). A situation can arises where restrictions are applied too heavily to the Windows\system32\inetsrv\ folder causing the cookies to break. Usually, these are IIS related problems more so than PortWeb.dll problems. Note that the PortWeb.dll is actually pretty simple and really doesn't do anything too abnormal to a system's configuration.
11. You might also consider that the (human) Portfolio Admin and Server Admin should discuss the additional permissions needed to allow the former to administer source files, Catalogues etc. It is important to note that accessing (a site's) adminshow HTML page requires admin permissions for the Portfolio Admin, or alternatively a specially created (admin) account for the same person. This factor is extremely pertinent if the PortWeb facility is being hosted remotely - and/or by a third party; the accesses and permissions need to allow the site's 'owner' to use the adminshow page functions without real-time tech assistance or intervention.
12. Some recommendations for permissions. These permissions "should" get the basic system up and running but systems your mileage may vary and there are no guarantees:
    • PortWeb.dll - Execute (everyone)
    • PortWeb.ini - Read (everyone), write & modify (admins)
    • PortWeb.wdb - Read, write, modify (everyone)
    • PortWeb.adm - Read (everyone)

PortWeb on Server 2003

Question: A non-tech's guide to installing (IIS hosted) PortWeb [FAQ00145.htm]
Last Update:- 02 June 2006

This FAQ is created and maintained using

Friday - The Automatic FAQ Maker