Ran into an issue quite recently about how to find about what edition of the SQL Server 2008 R2 is on one of our staging server.
There are a few solutions out there and normally I will haunt down the path by pulling out the server edition from the master table within the system database. However, this time I decided to try something different, something just out-of-the-box without fiddling things around.
After a bit Googling around, "SQL Server discovery report" caught into my attention. Basically, according to the MSDN entry, 'The SQL Server discovery report can be used to verify the version of SQL Server and the SQL Server features installed on the computer. The Installed SQL Server features discovery report displays a report of all SQL Server 2000, SQL Server 2005, SQL Server 2008, SQL Server 2008 R2 and Microsoft SQL Server Code-Named “Denali”, Community Technology Preview 3 (CTP 3) products and features that are installed on the local server. The SQL Server features discovery report is available on the Tools page on the SQL Server Installation center.'
So, let's quickly show you how to leverage the SQL Server features discover report to find about all those secret information:
Firstly, navigate to the "Start"-> "Microsoft SQL Server 2008" -> "Configuration Tools" -> "SQL Server Installation Center", then bring up the installation center by clicking on it
Secondly, browse to the "Tools" section, then click on "Installed SQL Server features discovery report" link to bring up the summary report
Lastly, enjoy the report and find all your information you are seeking for
Tips & Tricks
The SQL Server Discovery Report is saved to %ProgramFiles%\Microsoft SQL Server\100\Setup Bootstrap\Log\Options:
- You can also generate the Discovery report through the command line. Run “Setup.exe /Action=RunDiscovery” from a command prompt
- If you add “/q” to the command line above no UI will be shown, but the report will still be created in %ProgramFiles%\Microsoft SQL Server\100\Setup Bootstrap\Log\20091112_082147.
SharePoint 2010 Environment Setup - Post Installation Configuration and Tricks-n-Tips
Post- installation Configuration
Change your Site's Authentication provider (not central Admin) from "Classic" authentication to Claims Authentication
It can be done via PowerShell Script
Add-PSSnapin Microsoft.SharePoint.PowerShell $webApp = Get-SPWebApplication "http://sitename/" $webApp.UseClaimsAuthentication = 1 $webApp.Update() $webApp.ProvisionGlobally() $webApp.MigrateUsers($True)
- To create a new secure store target application for ‘Visio Services’ go to Central Administration | Application Management | Manage service applications | Secure Store Service
- Then go to Central Administration | Application Management | Manage service applications | Visio Graphics Service | Global Settings
- Check the Application ID under Unattended Service Account
- You should have entered an application Id here, if not create a Secure Store Target Application of type Group and then enter its Target Application ID for Visio Graphics Account.
Solve “Missing Server Side Dependencies – 8d6034c4-a416-e535-281a-6b714894e1aa” error
- Navigate to SharePoint Central Administration Page
- Click General Application Settings on left hand side Quick Launch bar
- Under Search, click Farm-Wide Search Administration to open farm wide search administration page.
Now, under Search Service Application click Search Service Application
Now restart the server by executing iisreset -noforce command on command prompt.
Add the local Administrators group to the SQL System Administrators
To fix the outstanding problems highlighted by the health analyser, go to the Central Admin site and click on the "Health Analyser" alert bar that appears across the home page, or click the "Review problems and solutions" link on the homepage.
Address Issue 'The server farm accoun should not be used for other services'
For each alert, open it up and work out what the alert is being thrown by, and what to do to fix it. For example:
The Services that are causing the problem are listed in the explanation field, however some of them are a bit Cryptic (Such as SPUserCodeV4 - This is actually the SharePoint Foundation Sandboxed Code Service!)
Under "Security" --> "Configure Service Accounts", the services are listed using "Friendly Names" - most of the time it's pretty easy to work out what the Cryptic name in the Health Analyser Message means for the service… however if you cannot work it out, just go through each one and find the ones with the Farm account selected.
Select the Service(s) in question and change them to something else (such as a common generic Services account)
Address Issue 'Built-in accounts are used as application pool or service identities.'
$tracingService.ProcessIdentity.CurrentIdentityType = "SpecificUser" $tracingService.ProcessIdentity.ManagedAccount = $managedAccount $tracingService.ProcessIdentity.Update()
# This actually changes the "Run As" account of the Windows service.
Then, open up computer management and add the same account to the Performance Log Users group on all servers.
Address Issue 'Databases exist on servers running SharePoint Foundation.'
The "Database Exists on the Same Server" issue will not go away, as we're using SQL Standard on the same server.
Address Issue 'Validate the My Site Host and individual My Sites are on a dedicated Web application and separate URL domain'
My Site host and My Sites will throw the same error if they are located in the same web app; however for a development environment this is acceptable.
Tricks & Tips
- If the developers install Visual Studio 2010 before installing SQL Server 2008 R2, then the express version of the SQL Server 2008 will get installed by VS2010 complete installation.
Therefore, that would be ideal to tick off the SQL Server express edition installation option when installing Visual Studio 2010. Alternatively, install VS2010 and SharePoint SDK in the very end stage of this procedure.
- Installing service pack and cumulative package are most important steps during the installation and setup phase, by which it can save a lot of hassle for further setup later on. Therefore, it’s highly recommended to install patches, and then run the windows updates before kicking off the server configuration.
- Moving SharePoint logs off C drive is just a quick approach to avoid the situation, where it runs out the space from the operating drive.
- The tip here is to use PowerShell, which is neat and quick solution to get this updated:
Set-ItemProperty ‘IIS:\Sites\SharePoint – 80′ -name logFile.directory -value ‘D:\SPLog\SiteLog’ Apart from that, we also can quickly update the SharePoint Diagnostic log files to the new directory by the following Powershell Cmdlet:
Set-SPDiagnosticConfig -LogLocation D:\SPLog\SPDiagnosticLog
- Moving away SharePoint databases from C drive is another pre-caution method to ensure that, the SharePoint application runs out the space along with the huge increate of the database growth.
A quick one I set up is to change the “Database default locations” to D drive or another other drive except for the C drive where your operating system sits. After restarting the server, whatever the new database SharePoint create from this database, it will go to the new directory we define earlier.
- a. http://geekswithblogs.net/manesh/archive/2010/05/28/building-the-ultimate-sharepoint-2010-development-environment.aspx
- b. http://p2p.wrox.com/content/articles/setting-your-sharepoint-2010-development-environment
- c. http://msdn.microsoft.com/en-us/library/ee554869.aspx
- d. http://blah.winsmarts.com/2009-11-SharePoint_2010_Development_Environment_-and-ndash;_Practical_Tips.aspx
- e. http://www.wictorwilen.se/Post/My-SharePoint-2010-development-rigs.spx
- f. http://www.alpesh.nakars.com/blog/powershell-to-change-sharepoint-diagnostic-log-file-location/
- g. http://sptwentyten.wordpress.com/2010/04/13/change-the-iis-log-file-directory-via-powershell/