SSRS Integrated Into SharePoint 2007

-
Sounded like a bit of fun.  Tussling with SSRS has always been a bit of a tiresome hunt around google finding caveat here, note there and undocumented feature after undocumented feature. 

So I thought I'd put somewhere what I have found.

Firstly and this one is a biggy:

SSRS R2 DOES NOT WORK WITH SharePoint 2007

This is really strange (or at least counter-intuitive) as we have SQL 2008 R2 so downloaded to accompanying SSRS R2.  A few fruitless hours later...

As SSRS R2 is for SharePoint 2010, instead of fixing SSRS R2 to work with SharePoint 2007 they fixed SSRS SP2 to work with SQL 2008 R2.  This is shown in one section of the "fix-list" in SSRS SP2.  Thanks.

Anyways, here is another gotcha:

If you have a multi-server environment (who doesn't?) then you need SSRS on each server...sounds ok, except the install doesn't care or ask about this so goes ahead and not only installs the binaries but activate the feature too.  This causes all many of nightmares on the SharePoint side as the next install sees the features already there and backs them out as the install think you are upgrading/repairing.  And then the second install fails and rolls back, leaving you worse off than you were before as the binaries are on the first server but not the second and the feature has been removed from SharePoint. *phew*

To get round this you need to run the setup program from the command line with the SKIPCA=1 switch which stops the installer activating the feature.  Not only does this work but has the added benefit of being faster too (oh and extracting all the files to the %temp% folder where you can run rsCustomAction.exe from there too). :)

So a suggested method would be to run the installer with the switch on all your servers in your farm except the last one and let this one activate the feature for you.

More to be posted when we figure out why we are gettin 401 errors...

Comments

Post a Comment

Popular posts from this blog

PXE booting, MDT and 802.1x

-
Image
Oh dear. We implemented site wide 802.1x when we moved. This has caused numerous issues which we are still tracking down and killing with fire. Again "only-when-we-needed-it" struck as we had a new starter and need to build a machine. Ah.   No PXE.  However thankfully we were able to make a bootable USB using 802.1x and get our build working again from MDT in our 802.1 environment. Here's how we did it.   Caveats:  I'm assuming you know MDT and how PXE works. We use Computer certificates as the 8021x auth method. 802.1x is working in our environment GPO is used to start the wired 802.1x service on built machines. GPO is used to configure the network profile to use 802.1x What you need Get a USB stick to take your WinPE 4GB may be enough Make sure you are running an up to date working MDT installation! Create a machine certificate which has a long expiry date, you don't want to be making USB WinPE images every month!! Export the machine
Read more

Intune installation requires a wire...or does it?

-
If you are using Intune (great!) it assumes you have a wired connection (not great) - this is more of an issue as some machine now no longer have built in ethernet ports. It is possible to connect to your wireless - albeit in a slightly awkward way.....here's how During the OOBE hit SHIFT+F10 to get a command window and type either; start ms-settings: To get the settings window or start ms-availablenetworks: To see the network fly outs. Thanks to  Using a wireless network connection with Windows Autopilot white glove – Out of Office Hours (oofhours.com)
Read more

Security Policy 1001

-
We had an annoying warning showing every 5 minutes on our Read Only Domain Controllers.  This didn't affect service but meant we were losing our logs of important events (should the have occurred) "Security policy cannot be propagated. Security Configuration Server (in services.exe) is not ready. This is probably in system reboot. Policy will be tried again in the next propagation." Source: SceCli Event: ID 101 We tracked this down to a GPO which was populating the local Administrators group. Obviously a Domain Controller has no local users or groups so this was causing the issue. Ensuring that the GPO did not apply to the Domain Controllers - yes the GPO was linked at the root! fixed the issue. It is strange that we did not see the warnings on our main Domain Controllers only on the Read Only DC's as this would have affected all DCs the same (I would have thought)
Read more