Two weeks ago today I left the building frustrated with Microsoft because of poor documentation. You can see my rant here.
I'm still a bit miffed that the "How to restore..." document was (and still is as of this writing) wrong, but I'm feeling better that they have graciously apologized to me. And the fact that with the help of Support, we're up and running in the restored test environment. Being I'll most likely forget, here are the steps we had to do to get this test restore environment up and running.
First support walked through the steps 1 - 14 of "Restore and Test SQL Report Server, Reporting Services, and Default Reports" BEFORE we did "Rename the Team Foundation Data-Tier Server and Activate the Team Foundation Application-Tier Server" AND "Move User and Service Accounts" section. Why? I'm not sure if I understood the reasoning.
Second, support did the following steps on the App Tier and Data Tier once I handed over support with Easy Assist.
1) App Tier: Before they ran RenameDT, they changed the ReportSever AppPool identity from NetworkService to the TFSReports account.
2) App Tier: They ran RSKeyMgmt.exe –d which deleted all encrypted data on the server
3) App Tier: They ran RSKeyMgmt.exe –r on the GUID from the initial install of TFS on this new hardware. Somehow this GUID gets re-added?
4) Data Tier: Opened up the tbl_database table in the TfsIntegration database and changed all the ‘servername’ values to the new Data Tier.
5) Data Tier: Opened the tbl_service_interface in the TfsIntegration database and changed ReportsService and BaseReportsURL to have the new App Tier name.
6) In Reporting Services Configuration, they made sure that the TFSReports account was used instead of a built in account.
After they did all this, the RenameDT worked. Like my first point, I'm not sure I understood why they did all this and if it was all really needed.
Third, after "Rename the Team Foundation Data-Tier Server and Activate the Team Foundation Application-Tier Server" we did the "Move User and Service Accounts" section. All this worked just fine.
Fourth, this wasn't really related to the restore per say, but we did have to give the AppTier\Users group Read, List, Read & Execute on the c:\Program Files directory. Without this, the only users that could log in where those who were members of the AppTier\Administrators group. I'm not sure if this is correct, or why the TFS install didn't set it up for us? When I compared this test restore hardware with our current PROD hardware, the current PROD hardware was configured with AppTier\Users have that access to c:\Program Files so we just mimicked the behavior and it all worked. UPDATE: We also had to give AppTier\Users Full Control access to %Program Files%\Microsoft Visual Studio 2008 Team System Web Access\Cache.
Fifth, we finished steps 15 - 29 of "Restore and Test SQL Report Server, Reporting Services, and Default Reports". This all worked fine.
Sixth, and lastly, we changed the Instance ID so that we didn't have the same Instance ID for both our current PROD hardware and our test restore hardware. See this full forum for how to do this.
After all this, we currently have a test copy of our current PROD system restored so we can play around with it.
Tuesday, April 15, 2008
Follow-up on our Restore Attempt(s)
Posted by
Mac Noland
at
1:21 PM
0
comments
Wednesday, April 09, 2008
What is needed to write complex Reports
There have been a number of people asking me what they need to install in order to get up and running with report writing using the "Business Intelligence Development Studio". Here is what I send them.
1) Install Visual Studio 2005. This step is optional.
2) Install "Microsoft SQL Server 2005 Express Edition Toolkit" which gives you the "Business Intelligence Development Studio (BIDS)"
3) Read Buck's blog and download the attached documentation to get your data sources setup and an initial report written.
4) Obtain a PHD in Computer Science if you have to write any MDX queries.
Posted by
Mac Noland
at
9:20 AM
0
comments
Labels: Reporting Services
Tuesday, April 08, 2008
IE 6.0 crashes with Share Point 3.0
Some of our users have had IE 6.0 crash on them (intermittently) while opening up documents from Share Point 3.0. While the error messages don't exactly match, they are similar to what's described in Steve's post.
I followed up with the users and it seems that Steve's fix, fixes their issues with IE crashing.
Thanks Steve for posting your find!!!! I'm hoping it will get me a free beer at the bar.
Posted by
Mac Noland
at
1:18 PM
0
comments
Thursday, April 03, 2008
Cannot create a connection to data source 'TfsOlapReportDS'. (rsErrorOpeningConnection)
If you ever see an error like below when trying to render a Report in TFS, make sure MS SQL Analysis Services is started under Control Panel > Services. Since we're running a duel server install, our MS SQL Analysis Service is running (or not running when we get this error) on the Data Tier.
An error has occurred during report processing. (rsProcessingAborted)
Cannot create a connection to data source 'TfsOlapReportDS'. (rsErrorOpeningConnection)
For more information about this error navigate to the report server on the local server machine, or enable remote errors
Posted by
Mac Noland
at
6:40 AM
2
comments
Tuesday, April 01, 2008
Frustrated with "How to: Move Your Team Foundation Server from One Hardware Configuration to Another"
Nothing frustrates me more than when documentation is wrong or misleading. Case in point: The document "How to: Move Your Team Foundation Server from One Hardware Configuration to Another" explaining how to move TFS from hardware to hardware is probably one of the worst written documents I've ever read. Here are just a few of my observations.
- We've bombed out at "To rename the Team Foundation data-tier server". The first issue was that a small, yet critical, detail is left out of the document. It's missing the statement explaining before running TfsAdminUtil RenameDT
- Even after getting past this, we are still stuck though. According the support, we actually should do the "Rename the Team Foundation Data-Tier Server and Activate the Team Foundation Application-Tier Server" and "Move User and Service Accounts" AFTER we do other things like "Restore and Test SQL Report Server, Reporting Services, and Default Reports" which is two sections BELOW "Move User and...". What? If this is true, which we're verifying with our field rep, why does the document have them out of order? How can someone expect to know this?
- Lastly, the support rep (who was actually very helpful by the way), said that you basically have to disconnect the old TFS server when you do the migration. Meaning, you basically can't do a test restore on some QA hardware before you have to come in on a weekend to do the same steps on a live PROD system. We're checking with our field rep to make sure this is accurate, but if it is, which I'm praying it's not, where in this document does it state that you must disconnect the old system before doing the restore based move?
Sorry for my rant. I just get so frustrated when documentation is wrong or misleading.
Posted by
Mac Noland
at
1:12 PM
4
comments
Thursday, March 27, 2008
Running Tests and getting Code Coverage for our .NET projects.
As I wrote about a last week, the entire testing portion of Visual Studio is a mystery to me. I've never been a tester (for good reason) so I've really never spent the time to dig into Microsoft's offering. That was until I was forced to figure some stuff out, due to my new team wanting it.
From what I've found, TFS 2008 makes executing user's tests at build time very easy. All we had to do is add the following line to our Team Build project file and the magic happened. We had test results!!
<TestContainer include="$(OutDir)\Unit Tests.dll">
The code coverage was missing though so we had to track that down. Thanks to Benday, all we had to do is update our Team Project file again and magically, we had coverage results.
<RunConfigFile>$(SolutionRoot)\LocalTestRun.testrunconfig</RunConfigFile>
Of course this assumed our testrunconfig was setup for Code Coverage, which in our case it was.
So far, even a testing novice has found it pretty easy to get tests to run at build time. Feel free to share you experiences, both good and bad.
Posted by
Mac Noland
at
12:50 PM
4
comments
Friday, March 21, 2008
Publishing Test Results using the Testers Edition of Visual Studio
I fully admit, I don't know anything about the Testers Edition of Visual Studio. However, since I know a bit about TFS, I've been asked a number of questions about how the two talk to each other. Thus it's been a learning experience for me!
Here is the way I understand the Test Results publishing process to TFS for the Tester Edition of VS. Again, this is all really new to me so if I have something wrong, please correct me.
Per the document here, I see that a Tester will run a test on their local machine or using the "rig" to run on remote machines. After the tests are run, test results are stored in *.trx file on the tester's machine. Testers then can open that file and "Publish" them to TFS's operational store (which must be the TfsBuilds database maybe?). That data then gets moved to the TfsWarehouse per the warehouse schedule. At this point, you can Report on it in the warehouse.
Now there seems to be one small deviation in that Load Tests need to be loaded to a local SQL database which is defined outside of TFS. That is, the Load Tests database stores Load Test data before it's published to TFS. There must be someway then that the Tester Edition of VS can look in that local database where the Load Test results are stored, and publish the results to TFS. I think this is an important detail as there may be some ambiguity on the difference between the Load Test database and the standard databases that make up TFS (e.g. TfsBuilds, TfsWarehouse, etc).
If I have anything wrong here, I'd love for you to share your insight as we're trying to put the big picture all together.
Posted by
Mac Noland
at
2:40 PM
1 comments
Labels: Test Edition
Wednesday, March 19, 2008
Teamprise 3.0 is released!
If you didn't see, Teamprise 3.0 has just been released. As I've written a number of times, Teamprise is a great offering if you're looking for a cross platform solution for Team Foundation Server. NO I do not work for Teamprise or sell their product for a living. I'm simply a customer at a large software firm who uses Teamprise for our Java development groups.
We use every piece of their suite including the Ant scripts and Teamprise Build Extensions which allows you to call your Ant scripts from Team Build.
Teamprise has a great product, but even a better support group. If you have not checked them out, do it soon. You'll find it being one of the best products around.
Posted by
Mac Noland
at
9:41 AM
0
comments
Labels: Teamprise
Monday, March 17, 2008
The "Copy" task could not be initialized with its input parameters
As I wrote about last week, we've started to use a few Tasks from Sdc. Per the instructions we started by importing the entire list of Tasks. Something like this.
Import Project="$(TasksPath)\Microsoft.Sdc.Common.tasks"
Doing this led to an error in our Team Build though.
...
(EndToEndIteration target) (1)
(CoreDropBuild target)
C:\Program Files\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets(1310,11): error MSB4064: The "SourceFiles" parameter is not supported by the "Copy" task. Verify the parameter exists on the task, and it is a settable public instance property.
C:\Program Files\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets(1309,5): error MSB4063: The "Copy" task could not be initialized with its input parameters.
...
I took a look in the Team Build targets file and sure enough, the Team Build targets file uses Copy, but needs the MSBuild one not the Sdc one. I'm guessing this is an conflict error in Sdc.
Using guidance from the forums, we had to change our global import to just import the TaskNames we needed. This helped us get around the issue with the Copy conflict.
UsingTask TaskName="Microsoft.Sdc.Tasks.Tools.PsExec" AssemblyFile="$(TasksPath)\Microsoft.Sdc.Tasks.dll"
Posted by
Mac Noland
at
11:02 AM
1 comments
Friday, March 14, 2008
Check out SdcTasks
We've taken a mass adoption of the SdcTasks found on Codeplex. When comparing MSBuild to Ant, I've always been disappointed with the Core tasks in MSBuild. The default list seems to be limited. NOTE: I have not done a task for task comparison, but only a cursory compare.
The limited task set in MSBuild is what has really excited me about SdcTasks. There is a ton of stuff in this add in. Want to talk to Active Directory, Email, or talk to SQL? Take a look at SdcTasks for help.
Since I'm lazy, I'd like to see these rolled into the standard install for Team Build or MSBuild.
Posted by
Mac Noland
at
2:24 PM
2
comments
Labels: Team Build