Reporting Services issue when installing local Domain Controller

Problem:
At a client we had to produce a server, in order for us to have a development environment, since they couldn’t spare the server power. Odd situation, but that’s not the point. The point is that, somewhere during the installation process of this server, after installing SQL Server, we noticed that the server wasn’t a domain controller. Now the SQL Server and in particullar Reporting Services (SSRS) was installed with credentials granted to the build-in Network Services account. This account gets a new SID once we installed the domain controller, and after that SSRS started acting on us.

Solution:
The new Network Services account needs to be granted modify permissions to the following folders:

  • C:\Program Files\Microsoft SQL Server\MSRS10.MSSQLSERVER\Reporting Services\LogFiles
  • C:\Program Files\Microsoft SQL Server\MSRS10.MSSQLSERVER\Reporting Services\RS\TempFiles

Loading

Parameter ordering in SSRS – Gotcha!

After banging my head against the screen for about three or four hours, trying to solve what seemed as a Reporting Services mystery, a coworker of mine came up with the solution. I was trying to inject a role into an embedded data source in a report, while loading data for several parameters, in order to utilize FORMS authentication on the website while respecting the Windows Authentication needed for Analysis Services.
I had one report going, 11 more to go, and then I got stuck on a data source string yada yada error. In Report Manager it looks like this:
The reason for this error, as it turns out, is that it would appear as if Reporting Services parses parameters one by one. In that way the first parameter in the list gets loaded by accessing the data source, and fails miserably if a parameter is used in the data source, that is not yet loaded/parsed/whatever…
Although Microsoft say they have several connect issue regarding this rather unfortunate issue, I can only find one: MS Connect

Loading

Reporting Services og lokal Domain Controller issue

Problem:

Jeg havde forleden den førnøjelse, at installere en Domain Controller lokalt på det udviklingsmiljø vi arbejder på. Vi har måtte troppe op med egen server, da kunden ikke kunne afse serverkraft til et udviklingsmiljø. Så maskinen står altså i et domæne vi ikke rigtig kan kontrolere.

Reporting Services, og i særdeleshed rsreportserver.config, håndterer det ikke så elegant som man kunne have ønsket sig. Servicen kører, i vores tilfælde, under kontoen Network Services, som erstattes i det øjeblik Domain Controlleren bliver installeret. Kontoen får altså tildelt en ny SID.

Problemet opstår fordi Reporting Services registrerer SID’en på Network Services, som jo erstattes. Hvorfor den nye konto ikke længere har adgang.

Løsning:

Giv kontoen Network Services rediger/modify rettigheder til mapperne: C:Program FilesMicrosoft SQL ServerMSRS10.MSSQLSERVERReporting ServicesLogFiles og C:Program FilesMicrosoft SQL ServerMSRS10.MSSQLSERVERReporting ServicesRSTempFiles

Loading

Sådan kan man jo blive så kåd…

Var til den famøse certificering i dag, men bestod ikke. Der skulle også have været en god portion hjælp fra opgavestillerne, før det havde rimelige udsigter.

De 53 spørgsmål jeg fik til testen, var tre-delt nogenlunde ligeligt på SSIS, SSAS og SSRS. Dog var der forholdsvis stor fokus på Data Mining og det dertilhørtende DMX. Det er så ikke lige noget jeg har så sulens meget hands on erfaring med. Det gør jo, at syntax spørgsmål pludseligt bliver møg-svære, og umulige at gætte på.

Men hvad… Vi må på den igen en anden dag.

Loading