SQL Reporting Services

Installing SQL 2000 RS

When you run the installation you get a pop-up warning about not having Visual Studio 2003 installed, this only affects Report Designer, and we can live without that.  You do need to make sure that SQL 2000 SP 4 is installed, or you get most of the way through, and then can’t choose the default Credentials Type – or rather the default is Service Account, but you can’t opt for that (http://support.microsoft.com/?id=821334)

When asked about which account you want the ReportServer Windows service to run under, I left this at NT Authority\Network Service, and I left the service at Auto-start.

For the Virtual Directory information I had the following defaults configured :

Report Server Virtual Directory: ReportServer

Report Manager Virtual Directory: Reports

Use SSL: This was ticked, but I unticked it, because I don’t have SSL configured.

Next you are asked about the Report Server Database :

SQL Server Instance: Evault1

Name: ReportServer

Credentials Type: Service Account

I left all those as-is.

There were 1 or 2 other items to fill in, but they are straight forward.  Installation then runs though.

EV 2007 Installing and Configuring Guide says :

Microsoft SQL Server 2000 Reporting Services with SP 2, or Microsoft SQL Server 2005 Reporting Services (SP1 recommended)

Troubleshooting article for EV Reporting :

http://atlas.veritas.com/avf/aca-1/dispatch.exe/mynotes/lookup/285815/0

Configuration

Need to try and make sure the installation fails, so let’s try configuring “My Reports” first of all.

Go to http://evault1/Reports, and login.  This is the first screen :

I now want to turn on “My Reports”, so that I can get the EV Reports installation to fail, to do that click on Site Settings, to go to :

On that screen tick the box for enabling the reports, and click Apply.

Installing SQL 2000 Reporting Services SP 2

This is just a small (20 Mb) executable to run.  It is listed as a pre-req for EV Reports so rather than suffer any problems, or a failed installation because of that, I installed that.

Installing EV Reports

Looks like you need to run evdeployreports.exe, however, I can’t find that !  So, to get the first run through I did :

* Stopped all EV Services

* Stopped IIS Admin Service

Then re-run the setup.exe from the EV installation CD.  This then gives the option (as a tick box) so that you can install reports.

Running for the first time

After restarting the IIS services, and EV, you now have an extra menu item called “Enterprise Vault Reports Configuration”.  You also have an EVReports folder underneath the main Enterprise Vault folder on the file system.  Clicking on that option in the start menu, brings up this screen :

I used the Vault Service account on this screen, though I really suspect that I should use something else.  I can check that in the Installation Guide.

After a few minutes, and a bit of IIS service restart action, I got a failure message :

And the log file (which is in the EVReports folder says) :

W3SVC is currently stopped so starting it
W3SVC is currently waiting to start
W3SVC started successfully
Leaving UIHelper::StartService
Leaving UIHelper::StartChild
Entered UIHelper::StartChild
Entered UIHelper::StartChild
Starting service :W3SVC
Entered UIHelper::StartService
W3SVC started successfully
Leaving UIHelper::StartService
Leaving UIHelper::StartChild
Starting service :HTTPFilter
Entered UIHelper::StartService
HTTPFilter started successfully
Leaving UIHelper::StartService
Leaving UIHelper::StartChild
Starting service :IISADMIN
Entered UIHelper::StartService
IISADMIN started successfully
Leaving UIHelper::StartService
Leaving UIHelper::StartChild
Leaving UIHelper::RestartIIS
Restarting IIS successful
Entered Configuration::CreateRootFolder()
Entered RsHelper::ListReportServerItems()
System.Web.Services.Protocols.SoapException: System.Web.Services.Protocols.SoapException: The value for parameter ‘Item’ is not specified. It is either missing from the function call, or it is set to null. —> Microsoft.ReportingServices.Diagnostics.Utilities.MissingParameterException: The value for parameter ‘Item’ is not specified. It is either missing from the function call, or it is set to null.
at Microsoft.ReportingServices.WebServer.ReportingService.GetProperties(String Item, Property[] Properties, Property[]& Values)
— End of inner exception stack trace —
at Microsoft.ReportingServices.WebServer.ReportingService.GetProperties(String Item, Property[] Properties, Property[]& Values)
at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
at ReportingService.GetProperties(String Item, Property[] Properties)
at Symantec.EnterpriseVault.Reporting.RsHelper.ListReportServerItems(String folderPath, Boolean recursive)
at Symantec.EnterpriseVault.Reporting.Configuration.CreateRootFolder()
at Symantec.EnterpriseVault.Reporting.Configuration.Install()
Symantec.EnterpriseVault.Reporting.DeploymentException: Error code: SoapError
at Symantec.EnterpriseVault.Reporting.Configuration.Install()
at Symantec.EnterpriseVault.Reporting.AppClass.Install(Configuration cnfg)
at Symantec.EnterpriseVault.Reporting.AppClass.ConfigureReporting()
Entered ReportDeployForm::DeployReportsCallback
Entered Configuration::Configuration()
Entered RsHelper::RsHelper()
Leaving RsHelper::RsHelper()
Leaving Configuration::Configuration()
Entered RsHelper::ListReportServerItems()
Symantec.EnterpriseVault.Reporting.DeploymentException: Error code: SoapError

Server stack trace:
at Symantec.EnterpriseVault.Reporting.AppClass.ConfigureReporting()
at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(RuntimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(IMessage msg, IMessageSink replySink)

Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.EndInvokeHelper(Message reqMsg, Boolean bProxyCase)
at System.Runtime.Remoting.Proxies.RemotingProxy.Invoke(Object NotUsed, MessageData& msgData)
at Symantec.EnterpriseVault.Reporting.ReportDeployForm.DeployReportsDelegate.EndInvoke(IAsyncResult result)
at Symantec.EnterpriseVault.Reporting.ReportDeployForm.DeployReportsCallback(IAsyncResult asyncResult)
Leaving ReportDeployForm::DeployReportsCallback

Fixing it Up

Go back to the SQL Reporting Site Settings page, and turn off My Reports.  Re-run the EVDeployReports.exe

Clustering Windows 2003 (for Exchange 2003) in VMWare

I must say it’s a LOT simpler than it used to be when I worked at Microsoft.  Okay there are still some hoops that you have to jump through, but overall, it’s not that difficult to do, and to get a “good” working cluster up in 2-3 hours or work, from scratch!  Below is a list of the steps that I took when installing a 2 node Active / Active (yes I know that’s bad!) cluster for Windows 2003 SP 2, and Exchange 2003 SP 2.

Creating the Base VMs

Create a custom virtual machine for Windows 2003 Enterprise, and try to allocate at least 768 Mb of RAM

Ensure that the disk that is created is IDE (Not SCSI)

Ensure that you have two network cards (both mine were configured to be host only)

You will need the .flp file from here, in order to install the VMWare SCSI adapter during Windows installation :

http://www.vmware.com/download/ws/drivers_tools.html

Installing Windows is as normal except that you should press F6 lots of times when the installation starts, so that you can specify the .flp file downloaded from the above link.  In order for this to work you add the virtual floppy drive to the server, but do not connect it until you get to the blue screen where you are asked about additional drivers.  After the first reboot, don’t be worry if you get an error about not being able to find NTLDR…  just disconnect the floppy drive, and restart!

The rest of the Windows installation is as normal, just carry on accepting all the defaults, and setting the language options.

Cluster Admin Account

I normally create a cluster administrator account, and then either make the account a member of the local administrators group on each node in the cluster, or more normally I just add the cluster administrator account to the domain admins group for the domain.

Configuring Windows

Firstly you should format the disks as Basic NTFS and assign drive letters.  I always like assigning Q to the Quorum disk.

Secondly you should ensure that the network cards are renamed (one should be MainLan, and the other HeartBeat).  Ensure that the HeartBeat network card is “out of the way” I used 10.0.0.1/255.255.255.0 to make sure it didn’t communicate with my ordinary VM’s

You then need to join the node to the domain, and preferably login using the Cluter Administrator account (I normally create one called clusteradmin)

Configuring Node 1

You run Cluster Administrator, and opt to create a new cluster.  You will be asked for username and password for the cluster administrator account, IP address of the cluster, and the network name of the cluster.  Afterwards you will be left with :

A cluster group called : Cluster Group

It contains the resources :

Cluster IP Address

Cluster Name

Disk Q:

Configuring Node 2

This time when you run Cluster Administrator, you opt to join an existing cluster.  All you need then is the name of the cluster, and the cluster administrator password.

Doing a failover

From Cluster Administrator you literally pick the group you want to failover, and then right click, and choose Move Group.  It can take 30-60 seconds for the resources to fully move over to the other node, on my environment the “slow” resource appears to be the Network Name resource in each group – I’ve not looked in to why that might be.

Applying Windows 2003 SP 2

I do this on the inactive node, and then restart it.

Installing a DTC

In the cluster group, you should add a cluster resource of the type Distributed Transaction Co-ordinator, otherwise you are not able to install Exchange.  This is described here :

http://technet.microsoft.com/en-us/library/be6c39e1-7432-4a5e-b638-57a7826f13f1.aspx

Installing Exchange

Before installing Exchange I made sure that the cluster administrator was delegated an Exchange Full Administrator role.  I just think that will save any problems in the future (I’m not sure it is necessary).

When installing Exchange on each node, the first process is to just lay down the binaries, in other words run Setup.exe, and follow the installation through.  This doesn’t create ANYTHING, just all the registrations, and file copying necessary.

You do that on each node, before going on to the next step.

Configuring Exchange

There isn’t really a lot that you have to do for this.  I always make sure that my cluster group has a nice name, so I can recognise it from the general cluster group.  Next you add in to that group a disk resource, an IP address and a network name.  The IP and network name are going to end up being the names and IP addresses that Outlook users and Exchange will use, so ensure it meets some sort of naming standings.

Once those resources are present, and online, you create a System Attendant resource and make sure it is dependent on the disk and network name resources.

You are then ready to online the resource, which might take a minute or two the first time you try it.

Installing the Exchange Server Pack 2

Installing the Exchange Service pack is good as well.  When you try to run the update.exe, and you get to the component selection screen, you can’t continue if the current node owns any Exchange Virtual Servers.  You get a nice warning saying that you must perform a failover of those groups (it doesn’t tell you which groups they are though).

After the installation of the binaries there is the obligatory restart required.

Now know doubt this is in the readme, or other instructions, but I was a bit purplexed after installing SP 2 that the node wouldn’t “hold” any of the Exchange resources.  So I paused the active node (to stop fail back), and then brought the whole virtual server group offline, before moving it to the node which I had just applied the service pack on.  I then brought the IP and Disk resource online, followed by the Network Name.  I then tried the SA resource, and got this message :

After a small amount of panicking, I checked the Application event log, and saw this :

So nothing is/was corrupted (as I first thought).  A simple right click in Cluster Administrator, and you can chose the option to Upgrade the Virtual Server.  Around 15 seconds later you get a confirmation pop-up saying it was successful.

You have to do the upgrade on each Exchange Virtual server on the cluster.  Once you’ve down the binary upgrade on one node, you can then do these steps to upgrade the virtual servers and move them to that node, followed by an upgrade of the binaries on the other nodes in the cluster.

Altering PST Chunk Size

So I couldn’t find anywhere where this was documented, but I had heard that you could.  What happens when doing a client side PST migration is that the PST is chunked down in to 10 Mb chunks, by default.  This is controlled through a setting in web.config, in your \Program Files\Enterprise Vault\WebApp folder.

By default we see :

<configuration>
<system.web>
<compilation debug=”true” />
<trace enabled=”true” />
<identity impersonate=”true”/>
<!–
See http://support.microsoft.com/default.aspx?scid=kb;EN-US;323246#7
httpRuntime Attributes:
executionTimeout=”[seconds]” – time in seconds before request is automatically timed out
maxRequestLength=”[KBytes]” – KBytes size of maximum request length to accept
useFullyQualifiedRedirectUrl=”[true|false]” – Fully qualifiy the URL for client redirects
minFreeThreads=”[count]” – minimum number of free thread to allow execution of new requests
minLocalRequestFreeThreads=”[count]” – minimum number of free thread to allow execution of new local requests
appRequestQueueLimit=”[count]” – maximum number of requests queued for the application
enableKernelOutputCache=”[true|false]” – enable the http.sys cache on IIS6 and higher – default is true
enableVersionHeader=”[true|false]” – outputs X-AspNet-Version header with each request
–>
<httpRuntime executionTimeout=”90″ maxRequestLength=”10000″ useFullyQualifiedRedirectUrl=”false” minFreeThreads=”8″ minLocalRequestFreeThreads=”4″ appRequestQueueLimit=”100″ enableVersionHeader=”true” />
</system.web>
</configuration>

The setting is maxRequestLength.

If you change it to say 2500, and restart the EV server (perhaps just IIS, I didn’t test that) then you will see much smaller chunks being sent to the server from the client.  I would think that this might be handy on clients where the network connection to the server isn’t very good/fast.

EV_RECYCLE_FREQUENCY

New to Enterprise Vault 2007 Service Pack 1 is a little tweak that can be made to the Notes.INI file on the Enterprise Vault Domino Gateway (EVDG) to change the “speed” at which temporary Notes databases are depersonalised, and renamed to blankX.nsf.  The House Keeping task polls the folder EV under your Domino data directory to work out if there are any unused EV_0000000x.nsf files.  If there are, then it depersonalises them, and renames them to blankX.nsf, so that they can be reused for subsequent retrievals.

You can add a setting called EV_RECYCLE_FREQUENCY=nn where nn is the number of seconds that you want the nEVHouseKeeping task to poll for unused temporary databases.  The default for this is 20 seconds, and if you use FileMon you will see the House Keeping task polling the files to see if they are still used.

The setting should be added to your Domino Server notes.ini, as shown below :

Using the setting as shown above will mean that the House Keeping task will poll for unused files every 2 minutes.