My IT Experiences

I cleared the Microsoft certification exam for SharePoint 2007, the MCTS for MOSS 2007 configuring 70-630 on Monday this week. The score was 1000 out of 1000 :) There were 76 questions and I had to go for the best answer for around 15 of them because it was bit tough, but I made it through.

I got some inspiration reading the Technet article Deploy by using DBA-created databases (SharePoint Server 2010) the other day. We can deploy SharePoint 2010 without the central administration (CA) database having the annoying GUID. If we run the SharePoint configuration Wizard after installation it will create content database with GUID. However, if we create CA content database using PowerShell we can have the database name of our choice. I have also referred to the SPModule PowerShell Scripts available from Microsoft. Here are the steps: 1. Run Setup on each server computer in the farm. You must run Setup on at least one of these computers by using the Complete installation option. 2. Do not run the SharePoint Products Configuration Wizard after Setup finishes. From the SharePoint 2010 Management Shell, use the New-SPConfigurationDatabase command to create a new configuration database,,for example: New-SPConfigurationDatabase -DatabaseName "SharePoint_Config" -Database

We used to receive this error while deploying "wsp" files on our MOSS farm. This happened only on one WFE and not on the other. I was sure there was some process blocking the file deployment because this was happening only on one WFE. After hours of head banging we figured out that we had a SharePoint backup third-party application configured on this WFE. This application was installed on this WFE. We had our production deployment window normally in the afternoon on weekedays and weekends. This error would not normally happen on the weekends. Combining all these we figured out that backup application was not running on weekend afternoons. We checked with the storage management team here to pause or kill all backup jobs on a weekday that we had a scheduled "wsp" deployment. Amazingly we did not receive this error. Then we rescheduled the backup jobs accordingly so that it does not conflict with our code deployment window and the issue was solved.

I was receiving this error on the "Report Server Web Service URL" on our SharePoint farm: Report Server has encountered a SharePoint error. ( rsSharePointError) Access to this Web Site has been blocked. Please contact the administrator to resolve this problem. This site URL is configured via Central Administration > Configure Reporting Services Integration > Reporting Services Integration if Reporting Server feature/Add-in is installed on the farm. After doing some research I found out that this page somehow enumerates through entire site collections before it throws this error. As part of troubleshooting step I checked if the domain user configured for reporting service is has sufficient privileges in the farm and also as local admin of the sql box, but this did not solve the issue. We raised this issue with the vendor and they made us update our SQL Server 2005 to latest SP and CU; still we had the error. The reason was nobody was sure if this er