PowerShell v2 ships with PowerShell ISE, that is much easier to use while working with scripts. This is available by default on Windows 7 and can be enabled as a feature on Windows Server 2008, using the following PowerShell command: Add-WindowsFeature PowerShell-ISE (a good example of when to use the Management Shell) You can now find PowerShell ISE shortcuts in the Start Menu > Accessories (do not use (x86) with SharePoint). If you are using Windows 8, click Window button, enter PowerShell to find the Tile, right click and add it to the task bar. From now on, right click on the PowerShell Icon and click PowerShell ISE to load our new tool, see graphic below.

Figure 1: Launching ISE from Windows 8

Figure 2: PowerShell ISE in action

However, when you start PowerShell ISE, you’ll find that it only works with Windows cmdlets. For PowerShell ISE to work with SharePoint cmdlets (or other technologies), you’ll need to add a PowerShell Snapin with a few other recommended settings. You will want these setting to load every time ISE loads so modify your PowerShell Profile to host the correct commands as follows. (for Steps 1 - 3, copy and paste the code into a new Tab in ISE and run it by clicking F5)

1. Create a new profile page for all users

     if (!(test-path $profile.AllUsersAllHosts)) 
     {new-item -type file -path $profile.AllUsersAllHosts-force}
  
2. Edit the new profile, this will load the newly created page in ISE
 
     psEdit $profile.AllUsersAllHosts

3.  In the open page, right in ISE, called profile1.ps1, add the following code to the page and click save 

     $ver = $host | select version
     if ($ver.Version.Major -gt 1) {$Host.Runspace.ThreadOptions = "ReuseThread"}
     Add-PsSnapin Microsoft.SharePoint.PowerShell
     Set-location $home
 
  
4.  Save profile.ps1 page and close PowerShell ISE, re-open ISE and try running SharePoint commands such as Get-Command *SP* to return list of SharePoint cmdlets.

I hope you enjoy your new found methodology to run PowerShell Scripts in SharePoint or most other Microsoft Technologies.

See the Script here up on TechNet

See the Script here up on TechNet

Here is a PowerShell script that is designed to work in SharePoint 2007, 2010 and 2013. Comment out/in the sections that apply to your Farm. Set it to run as a scheduled task in the Windows Task Scheduler, for an appropriate time, shortly after the App Pools Recycle and before the important users starts using your system, typically at 5:00 AM.

If you have a load balancer in place, use IP addresses instead of the host header name. You may have to adjust your IIS settings to allow your site to respond to IP address directly.

Here is a link to my Script

Documenting a moving target is difficult, things are changing every day, features are added, content databases grow, quotas change etc. The first step is to baseline your configuration so you can compare settings to the previous months or years so when something goes wrong, you can compare and find out exactly what and when it changed. It is imperative to set up a process for documenting your Farm and will especially come in handy when troubleshooting problems. Implementing a manual process is doomed to failure. PowerShell and SharePoint lists to the rescue.

Why not create a SharePoint Site and store all your settings in various lists. You can use all of SharePoint goodness to filter, sort, search and compare. You have one place to go to check your settings and to find what you are looking for efficiently because this is what SharePoint is good at. But you do not have time to create lists and populate them with current data. The PowerShell script below is the first in a series of scripts I made that automates the entire process. I start with capturing the main Farm level objects and properties and will later capture Web Apps, Service Apps, Features, site collections until every property of every object is in a list for quick access to the Administrator or the Troubleshooter.

To see the script click here

I have another script that will install Project Server 2013 including the BI Center so between the 2 scripts, you don't have to use the UI at all to get Project Server 2013 Preview up and running on Prem. The whole process of going from green field server to running reports can take minutes not hours now. I also have a script to populate the instance with Projects and Tasks so you can quickly start using Project Server 2013 to get a feel for the new feel including performance.

Here is a link to my Script

Enjoy

In my Project Server 2013 lab I was able to create 100 projects in just over in 5 minutes  (10 tasks in each and 10 Resources on the Resource Sheet). My Lab is a Core i7 Laptop, 16 GB Ram and an SSD. I am using Windows 8 Preview with Hyper-V. I allocated 1 processor to the SQL VM and 4 processors to the Project Server VM. The Project Server instance is Vanilla, no custom fields and no permission changes. On the same hardware and VM configuration, I created a vanilla 2010 instance and performed the same test, the result was a slight performance improvement. The testing did not go so well on 1 or 2 processors allocated to the Project Server VM.

There was considerable performance improvement in the usability of Project Server 2013 over 2010 version, meaning that loading Project Center and all other pages was considerably faster even when I loaded a 1000 projects into the system.  In Project Center, it was incredible how fast I could filter out a few projects from a 1000 projects using Project Name field, it was instant.

Here is a link to my script, please try it out and provide feedback.

Personally I like to use this script in PowerShell ISE environment. If you do not know about this tool here are some details. https://technet.microsoft.com/en-us/library/dd315244 or https://technet.microsoft.com/en-US/library/dd819451.aspx. What I do is select portions of the script with my mouse and run with F8 command. This way you can see step by step what the script is doing. When you finish setting all the variables to suit your environment and test for a while, you can run it as a script in PowerShell Console. If you want to use the ISE, you can install it on Windows Server 2008 R2 from Server Manager, Add Feature.

Basically the scrip asks if you want to create a new OU or not, new AD Groups or not and new Accounts in these groups or not. When it asks to create accounts is asks how many, what Prefix to use, what AD group to drop them into and a starting point for sequential numbering of each user. If the OU or AD groups already exist it will notify you and keep going. If you try to enter duplicate users it will error and keep going.

 Here is a link to my script, enjoy.

  There are several storage mechanisms  available, including the hierarchical object store, configuration files, property bags, and SharePoint lists. Each mechanism has advantages, disadvantages, and sometimes risks—for example, SharePoint property bags provide an easy-to-use storage mechanism, but developers risk corrupting the configuration database or the content database if they attempt to persist non-serializable types. This is a great MSDN article about the pros and cons of each mechanism. https://msdn.microsoft.com/en-us/library/ee413935.aspx  (applies to 2007 and 2010 versions of SharePoint). You should not store a connection string in a Web Part unless you find a way to encrypt it because a user can export the Web Part from a page and can see all properties, including any connection string data even access accounts and passwords if not done right.

The most popular choice Web.Config

To add a connection string to the Web.config file, you can simply add a “connectionStrings” section between the closing (</SharePoint>) and opening ( <system.web>) elements.

</SharePoint>
<connectionStrings>
<add name="MyConnectionString" connectionString="Data Source=serverName;Initial Catalog=DemoDB;Persist Security Info=True;User ID=userName;Password=password;"/>
</connectionStrings >
<system.web>

Another manual way to add a connection string to a web.config file is from IIS. In IIS 7 click on your Web Application and double click connection strings Icon (see graphic below) and simply add a connection by filling out the form. You can set an account and password but it will not be encrypted. It is equivalent to adding a string manually per above step, there is nothing special here. It is not a best practice in multi-server Farms with many servers because of extra manageability burden put onto the Farm Administrator. Manual configuration is never a best practice in multi-server Farms.

If you do decide to use the Web.config in production environments you should always encrypt passwords before storing them in files. For more information, see MSDN for encrypting connection information at: https://msdn.microsoft.com/en-us/library/ms178372.aspx. This also needs to be done in the Web.config files of the target web applications on the destination servers, a very manual and error prone process.

Walkthrough: Encrypting Configuration Information Using Protected Configuration

Best Practice if choosing Web.config

1. Settings may be stored in the Web.config file only when SharePoint, Internet Information Services (IIS), or ASP.NET needs access to these settings to be able to operate.
2. When adding connection strings to web.config, your Developer should use the SPWebConfigModification class in a feature event receiver in a WSP, this will update the SharePoint Web.config file automatically including all destination servers. Typically the web.config update will happen when the feature is activated (or removed when the feature is deactivated).
3. Never edit the web.config file by hand, these settings can disappear on you. See what Joel has to say about this.
4. This is a must read article from MSDN. https://msdn.microsoft.com/en-us/library/ee855123.aspx. It provides options and sample code for storing configuration settings in SharePoint, it applies to 2007 and 2010 versions of SharePoint.

Choosing to use the Secure Store

Using Secure Store in SharePoint 2010 is an optional and highly recommended place to store and encrypt the user name and password for access by custom coded solutions. The secure store service provides a way for Farm Administrator to store credentials securely rather than hard coding them in code or configuration files. This can simplify the manageability aspect of having to encrypt portions of the Web.config file plus if hands over more control to the Farm Administrator to centrally manage access accounts and passwords. Below is a sample code block from the SDK at this url https://msdn.microsoft.com/en-us/library/ff625799.aspx. and it shows a way to get the credentials from Secure Store (assuming correct permission levels of course). The balance of the connection string data such as server name and database can be stored in a place of your choosing and many choose a SharePoint list in Central Admin site but remember about recoverability in disaster scenarios, the Central Admin site may not be restorable.

Secure Store can help you with NTLM “double hop” issues where credentials cannot be transferred across more than one computer boundary because typically the Secure Store is one hop away from the SQL data. . SP2010 is making it easier to create more sophisticated enterprise solutions.

private static string GetCurrentDMSUsername()
{
    string result = null;

    ISecureStoreProvider secureStoreProvider = SecureStoreProviderFactory.Create();

    using (SecureStoreCredentialCollection credentialCollection = secureStoreProvider.GetCredentials(SecureStoreApplicationID))
    {
        foreach (SecureStoreCredential credential in credentialCollection)
        {
            if (credential.CredentialType == SecureStoreCredentialType.UserName)
            {
                result = GetStringFromSecureString(credential.Credential);
                break;
            }
        }
    }

    return result;
}

See another Code Snippet: Get User Credentials Using the Default Secure Store Provider

Application Setting Manager for Large Scale Farms

Because of the complexities in choosing and implementing an appropriate strategy for the storage of configuration data, such as connection strings, the SharePoint Guidance team has developed an optional reusable component named the Application Setting Manager. You can use it in your SharePoint applications to provide an easy, consistent, and type-safe means of storing and retrieving configuration data at any level of the SharePoint hierarchy. Because it uses property bags as its underlying storage mechanism, the Application Setting Manager is not suitable for storing large payloads. If you need to store data exceeding 4kilobytes (KB) in size, you should choose an alternative approach to storage. For example, you can configure the Application Setting Manager to use list-based property bags.

Performance

The potential for a significant performance problem is very real if retrieving credentials or other settings is done incorrectly. Caching is usually needed in busy SharePoint custom solutions. SharePoint presents some unique challenges that must be taken into account mainly because of the multi-server nature of a typical SharePoint Farm. You must also be aware of the volume of content that you are storing in cache and make sure that this is not presenting the very same performance problems you are trying to prevent. Performance is always a trade-off and  Knowledge of your application along with testing are the only ways to legitimately tune everything appropriately.

Final Recommendations

So what is the right answer? Like so many things in SharePoint, the answer is inevitably it depends, or perhaps the answer is really a combination of these options. Global items should go into the hierarchical object storage or a property bag scoped to the farm or Web application. Items scoped at a lower level should be implemented via a property bag attached to the appropriate item - SPSite, SPWeb, SPList, SPListItem, etc. - or in a SharePoint List. Deciding which option(s) work for your application is a factor of many things, including a degree of personal preference.

Regardless of which option is chosen, a few recommendations can be applied globally:

• Consider caching frequently-used or expensive-to-retrieve values in memory. Your backend storage is still any one of the options presented here; you just have a mechanism for reducing the performance impact of accessing the values.
• It is important that you have a standard mechanism for reading from and writing to the persistent store. Typically this is accomplished by means of a utility class with a bunch of static methods to handle retrieving and storing values. Besides the obvious benefits of this approach, it also allows you to easily change the back end storage without impacting any of the rest of your application. If all your application needs to do is make a call to SettingsManager.GetValue() and pass in the name of the setting value it needs, it doesn't matter whether that value is coming from a SharePoint List, an external database or the hierarchical object storage - the utility class insulates your application from those details.
• Similar to above, have a common place where all settings for your application are managed - especially if you are using multiple storage options. Don't force administrators to know where each setting is stored (hierarchical object storage, list, property bag, etc.) to know where they need to go to in order to manage that setting. Have your application do the heavy lifting and pull all of that functionality together in one place for your application.
• One final recommendation is to set your standards and stick with them. Few things can make an application seem less professional and less well-thought out than a seemingly arbitrary use of different options for storing configuration settings. Know why you are using each option and make sure that it is consistent with the rest of the options chosen for your environment.

Additional Resources

https://msdn.microsoft.com/en-us/library/ff829215.aspx

­A step by step guide in designing BCS entities by using a SQL stored procedure (Jyoti Saikia)

https://msdn.microsoft.com/en-us/library/gg552610.aspx

Technologies for Creating SharePoint Applications https://msdn.microsoft.com/en-us/library/gg454784

Updates to this blog, Aug 1, 2012

What about using odc files for your custom apps? Like they do in Excel, read this.  https://blogs.msdn.com/b/sharepointdev/archive/2012/02/09/how-to-programmatically-update-an-odc-file-shubh-raj-singh.aspx