SharePoint Pre-Upgrade/Migration Checklist

Here are excerpts published by Metalogix. It covers a lot of Pre-upgrade/migration scenarios that could help track down or prevent upgrade/migration issues. I have personally applied a lot of these in my projects in the past, especially environment clean-up activity, where we would ideally delete Orphan sites/site collections, unused sites, unused groups/user accounts, track down large site collections, break them down to smaller site collections, archive old records and apply database level maintenance plans.

Here are the key excerpts from the White Paper:

INTRODUCTION
No migration to SharePoint 2013 should be taken lightly. SharePoint content has grown at a remarkable rate of 75% annually. With that growth, your company’s users demand 100 percent up time and expect few or zero lapses in their ability to access business-critical sites. The IT department, meanwhile, must ensure that only the right people can access certain content while overseeing a smooth, error-free transition that will minimally impact their workload.

Its a simple message: “Clean up your current SharePoint environment today and planning out your future migration to SharePoint 2013 will save you time, money and headaches.” The complexity lies, however, in determining what to cleanup and how to plan for a successful migration.

Cleanup offers two major gains for SharePoint 2013 migration. First, it will increase the performance of your current environment by removing resource-intensive tasks. Second, it will expedite the overall time required to move from your current SharePoint environment to SharePoint 2013.

PRE-MIGRATION OF USERS AND GROUPS

No SharePoint environment would be complete without users. During the pre-migration analysis, identifying inactive and active users and groups not only helps you understand their post-migration expectations, it also gives administrators an opportunity to ask why these users are not using SharePoint for their collaboration needs. The result is less overhead and improved communication with your SharePoint users as you migrate to SharePoint 2013. The following sections explain how to identify these users

IDENTIFY INFLUENTIAL USERS

Including your influential users in the planning and implementation stages of your migration can prove beneficial to the success of the migration. Users can provide both “on-the-ground” feedback during the migration and communicate their SharePoint 2013 requirements and expectations.

Start by identifying the most active SharePoint users and sites in your environment by writing Powershell scripts. Communicate with these users throughout the process and help get early “buy-in” so that they will in turn communicate any changes or new features to their team. Some of the examples of Powershell scripts that SharePoint Admin/developer could write are Site Risk Assessment to gauge largest sites/site collections, content DB size, orphan sites, unused sites, large lists, complex workflows, orhpaned users/groups etc.

REMOVE ORPHAN USERS

One often overlooked area of the cleanup process is removing orphan users. These are employees who are no longer with the company and were removed from Active Directory but still have a SharePoint user account and associated permissions for sites or content.Orphan users may also have active SharePoint alerts or My Sites. While orphan users can no longer access the content, if they’ve created alerts, My Sites, and other mechanisms in your environment, those can impact SharePoint’s hardware resources. Cleaning out these users before your migration will help teams gain back resources and better predict SharePoint user growth.

CLEANUP UNUSED SHAREPOINT GROUPS

When new site collections are created, often the default SharePoint Groups (owners, contributors, etc.) are also created (intentionally or not). Frequently, only a few of those groups are used.  This information is valuable as you plan for your migration and can help reduce the number of Client Access Licenses (CALs) needed and reduce your user footprint. It’s also an opportunity to reach out to inactive users who are still with the organization to ask why they’re not using SharePoint.

CLEANUP UNUSED SITES

Unused sites that contain almost no content or have very limited activity are excellent candidates for archiving as you prepare the migration process. You can find under-utilized sites within any scope (Site Collection, Web Application or even the whole farm) and filter the report to display certain site definitions.

BREAKUP LARGE SITE COLLECTIONS

Site Collections (or sites) often outgrow their original size. This suggests that users are actively engaged in SharePoint. It also points to a potential resource issue. Very large site collections can impact performance which in turn will likely hinder your migration plans.

Typically, it makes sense to split the Site Collection during the migration process. Or you may want to split the content so that some of your users can migrate to SharePoint 2013 and start using it, while other groups use SharePoint 2010.

FIND LARGE SITES (AND PROMOTE TO SITE COLLECTIONS)

As part of a migration plan, you might decide to reorganize your sites and promote some of them to site collections based on their size. For example, all sites above 100 GB might be candidates for promotion to Site Collection.

Microsoft has documented best practices for the size of Site Collections that should be followed. http://technet.microsoft.com/en-us/library/cc262787(v=office.15).aspx#SiteCollection

FIND SMALL SITE COLLECTIONS (AND DEMOTE TO SUBSITES)

Another opportunity for cleanup is to identify small site collections and demote them to subsites. Often user requests for sites are satisfied by creating site collections. Over time, it might become apparent that those site collections could or should have been created as subsites of a different site collection. Another outcome of this analysis might be that you choose to just delete those site collections since they have very little use.

IDENTIFY AND MANAGE LARGE LISTS

Microsoft’s best practices for numbers of items in a list or folder are often exceeded due to the unanticipated growth of SharePoint. Using the Most/Least Storage reports generated out of PowerShell, you can identify large lists with excessive number of items. During the migration you are then in a position to split those lists.

You can also use the List Property report to analyze the columns to determine whether they are approaching the Microsoft recommended list view thresholds (2,000 or more items with 20 or more columns).

CLEANUP CONTENT

With Powershell, you can generate the List and Library Storage report includes last accessed and/or last modified metadata. With that knowledge, you can choose to archive some of the content as part of the migration effort and/or the migration can be configured to skip older content that is no longer needed.

Another effective way to maintain control over content growth is to implement policies around versioning. Using Powershell scripts, you can gain insight into the storage impact of the document versions. The more versions an item has, the slower the migration of the item will be. With Powershell, you can use Set List Properties to configure versioning across any scope in the farm. The script can then configure SharePoint to automatically prune the versions from the content.

REMOVE DUPLICATE FILE

It’s not uncommon for SharePoint to be the repository for the same document in multiple places. To improve the migration performance and reduce user confusion, write a script to remove Duplicate Files

ARCHIVE THE AUDIT LOG

Powershell scripts can be written to move the Audit Log data from source content databases and stored in a standalone SQL database. This provides access to audit information even after you’ve moved to the new SharePoint version. Once the data is in the archive, you can use SQL Server Reporting Services or other tools can also be used to create audit reports after migration. This ensures a continuous audit trail even after the farm is migrated.

WEB PART DECISIONS

Web parts are used everywhere – your SharePoint environment probably includes Microsoft web parts, custom web parts, and third party web parts.

As you plan your migration, it’s important to get an accurate assessment of the impact of any custom web parts used in your environment. This step will help you determine whether to update a custom web part so it works in 2013 or deprecate the component as its functionality is no longer needed or has been replaced by a new capability in SharePoint 2013.

Web part usage analysis will also assist in determining if support/maintenance on third party web parts should be continued or not. We can write Powershell scripts to report out Webparts on the page.

Web Part analysis helps you can gain global insight into which web parts are being used and which sites they are being used on. The report can even filter for the Closed or Hidden web parts.

The Web Part report can be run by site administrators or distributed to them so that they can understand which components will be migrated and which will not. This will set end user expectations and prevent miscommunication during migrations.

WHERE ARE THE WORKFLOWS?

The Workflow repotrs could be generated via Powershell to find out details about workflow definitions, instances and their state. This information is particularly important for migration since it displays the details for all the in-progress workflows that cannot be migrated.

ARE THE CONTENT TYPES BEING USED

Content types are a powerful tool in SharePoint that enable organizations to organize, manage, and handle content in a consistent way across site collections. Gaining insight into the custom content types and where they are being used will help determine how the data will be managed once you migrate. Investigating the use of Content types will also help to highlight opportunities for creating enterprise content types that will provide broader scope.

Content Type report can be generated and filtered to show all content types or ones that are defined but not used. This information can be used to clean up the content types prior to the migration.

SHAREPOINT PERMISSIONS HIERARCHY

Using Powershell scripting reports, we can report out SharePoint sites/subsites that have broken inheritance and have unique set of permissions. This gives more insight on the complexity of permissions structure and also determines whether these sites should have ideally broken permission structure or not.

Alternatively you could use Metalogix tools known as ControlPoint and Content Matrix to report out all the above Pre-migration checklist parameters.

Developing Secure applications using Microsoft C#.NET - A primer

Here are some of the most important Security concepts/best practices on developing secure code using Microsoft C#.NET framework.

Threat Modeling:
a. Threat modeling involves understanding the complexity of the system and identifying all possible threats to the system.
b. These threats are analyzed based on their criticality and likelihood.
c. Decision is made whether to mitigate the threat or accept the risk associated with it.
d. Look at the system from the perspective of an adversary to help designers anticipate attack goals and determine answers to questions about what the system is designed to protect,and from whom.

Threat Modeling -Steps:
The threat modeling process consists of the following three high-level steps:
• Characterizing the system
• Identifying assets and access points
• Identifying threats.

Characterization:
• Characterizing the system involves understanding the system components and their interconnections, and creating a system model emphasizing its main characteristics.
• Then assets and access points of the system are identified.
• Identifying threats creates a threat profile of a system, describing all the potential attacks that need to be mitigated against or accepted as low risk.

Data Flow Diagram:
A data flow diagram (DFD) is a graphical representation of the "flow" of data through an information system, modeling its process aspects.
• DFDs can also be used for the visualization of data processing (structured design).
• A DFD shows what kind of information will be input to and output from the system, where the data will come from and go to, and where the data will be stored.
• It does not show information about the timing of processes, or information about whether processes will operate in sequence or in parallel.

Threat:
• The goal of this step is to identify threats to the system using the information gathered so far. A threat is the adversary’s goal, or what an adversary might try to do to a system
• Sometimes a threat is also described as the capability of an adversary to attack a system.
• The best method for threat enumeration is to step through each of the system’s assets, reviewing a list of attack goals.
• Assets and threats are closely correlated. A threat cannot exist without a target asset.

STRIDE:
• The output of threat identification process is a threat profile for a system, describing all the potential attacks, each of which needs to be mitigated or accepted. In general, threats can be classified into six classes based on their effect:
• Spoofing-Using someone else’s credentials to gain access to otherwise inaccessible assets.
• Tampering-Changing data to mount an attack.
• Repudiation-Occurs when a user denies performing an action, but the target of the action has no way to prove otherwise.
• Information disclosure-The disclosure of information to a user who does not have permission to see it.
• Denial of service-Reducing the ability of valid users to access resources.
• Elevation of privilege-Occurs when an unprivileged user gains privileged status.

Attack Trees:
• Attacks are modeled through the use of a graphical, mathematical, decision tree structure called an attack tree.
• Attack trees are constructed from the point of view of the adversary. Creating good attack trees requires that we think like an attacker.
• In an attack tree vulnerability model, the topmost (root) node represents an objective that would be of benefit to one or more threat agents.

Attack Tree:
Attack trees provide a formal, methodical way of describing the security of systems, based on varying attacks. You represent attacks against a system in a tree structure, with the goal as the root node and different ways of achieving that goal as leaf nodes.

Mitigation:
• Once all potential threats have been analyzed and the threats that must be mitigated have been determined, the next task is to specify security requirements. A requirement is a statement of goals that must be satisfied. A security policy can be considered a set of security requirements.
• A good security system strikes a balance between what is possible and what is acceptable via the risk management process.
• The simplest way to prioritize threats is by using two factors: damage and likelihood.

Risk Management:
There are four possible ways to manage a risk:
• Accept the risk -The risk is so low and so costly to mitigate that it is worth accepting.
• Transfer the risk -Transfer the risk to somebody else via insurance, warnings etc.
• Remove the risk -Remove the system component or feature associated with the risk if the feature is not worth the risk.
• Mitigate the risk -Reduce the risk with countermeasures.

The Three Pillars of .NET Security:
• You use authentication to ensure that you have correctly established the identity of a user.
• Once you have authenticated and identified a user, you authorize (authorization) the user to access one or more restricted resources.
• In terms of software security, when we trust someone, we grant that person access to one or more restricted resources;

.NET Security Namespaces
System.SecuritySystem.Security.Cryptography
System.Security.Cryptography.X509Certificates
System.Security.Cryptography.Xml
System.Security.Permissions
System.Security.Policy
System.Security.Principal

Assembly
An assembly contains Microsoft Intermediate Language (MSIL), metadata; an assembly contains the code that the common language runtime executes and description of the assembly itself. The .NET Framework uses the assembly as the basic unit of deployment and versioning and, most importantly as the basic security boundary. As such, assemblies are considered to be security surfaces.

Strong name
Strong names are used to protect assemblies –particularly shared assemblies.
• Simple name
• Version number
• Culture
• Encoding from the public / private key token

sn-k MyKeyPair.snk

Obfuscation
Obfuscation is the technique of altering the MSIL statements so that the application executes in the same way, but the output of a decompileris unreadable. Primary techniques
• Encryption
• Randomize symbolic names
• Application logic more difficult to follow
• The other alternative is writing security modules in native code.

CLR and Security
• Isolation with Application Domains
• Type safe code
• Unsafe code
• Verification
• Isolated storage
• Runtime security policy

CLR and Runtime Security Policy
• The runtime establishes the identity and grant set of an assembly when the assembly is loaded. You cannot alter the identity of an already loaded assembly to change the permissions granted to it.
• It inspects various characteristics of the assembly (evidence) to determine an identity for the code.
• The runtime uses the assembly’s evidence as input to a process named policy resolution.
• The result of policy resolution is a set of protected operations and resources to which the code within the assembly has access (permissions).

Evidence
The evidence objects you will most commonly use to define the identity of your assemblies are the seven standard evidence classes from the System.Security.Policynamespace:
• ApplicationDirectory
• Hash
• Publisher
• Site
• StrongName
• Url
• Zone

Permission request operations
• Requesting minimal permissions
• Requesting optional permissions
• Refusing permissions
• Permissions
• DnsPermission
• PrintingPermission
• SocketPermission
• FileIOPermission
• ReflectionPermission
• RegistryPermission
• UIPermission
• And more

Code Access Security Explained
The .NET Framework includes an important new feature known as code-access security (CAS), which provides fine-grained control over the operations and resources to which managed code has access. With CAS, access is based on the identity of the code, not the user running it and enforcing permission sets.

CAS is effectively another layer of security that managed code must pass through before it can interact with protected system resources, such as the hard disk and the Windows registry.

Permission sets
• Creating, deleting, and modifying files and directories
• Reading from and writing to the Windows registry
• Using sockets to accept or initiate a network connection
• Creating new application domains.
• Printing
• Code Access Security is the enforcement of security policies at the code level.
• Imperative security statements appear in the body of your methods and functions, which means they end up forming part of the compiled intermediate language (IL) code contained in your assembly.
• Declarative security statements are expressed using attributes, which are statements compiled to form part of an assembly’s metadata.

Imperative
public void CreateFile( ) {
// Create a new FileIOpermission object
FileIOPermissionperm = new FileIOPermission(
FileIOPermissionAccess.Write, @" C:\SomeFile.txt");
try {
// Demand the FileIOPermission
perm.Demand( );
}
catch (SecurityExceptionse) {
// Callers do not have necessary permission
}
// Method implementation...

Declarative
[FileIOPermission( SecurityAction.Demand,
Write = @" C:\SomeFile.txt"]
public void CreateFile( ) {
// Method implementation...
}

CLR
The .NET Framework provides a generic role-based security mechanism to represent the identity and roles of the user on whose behalf code is running.

.NET’s role-based security interfaces provide a standard mechanism through which you can make runtime security decisions based on the identity and roles of a user.
Namespace: System.Security.Principal

Roles
The process of determining what actions and resources a user has authority to access. A person’s authority is expressed in terms of roles. A role is a logical categorization that grants members of the role specific permissions.

An identity represents the user on whose behalf code is running. Normally, this is the currently logged-on Windows user, but this is not always the case. If your application authenticates users against an authority other than the Windows account system, then the identity may be different to the currently logged-on Windows user. A principal encapsulates an identity and the roles to which the identity belongs. Represented by the IPrincipaland IIdentity.

// Create a GenericIdentityfor the user Peter
GenericIdentitygi= new GenericIdentity(" Peter");

// Create a GenericPrincipalfor Peter and specify membership of the
// Developers and Managers roles
String[] roles = new String[]{" Developers", "Managers"}; GenericPrincipalgp= new GenericPrincipal( gi, roles);
// Assign the new principal to the current thread Thread.CurrentPrincipal= gp;

Impersonation
Sometimes, you will want your code to act at the operating system level as though it is a different user than the one currently logged on. This is particularly common in server applications that process requests from different users and need to access resources, such as databases, on behalf of the user.

[assembly:SecurityPermission( SecurityAction.RequestMinimum, UnmanagedCode= true)]
public class WindowsImpersonationTest{
[DllImport(" advapi32. dll", SetLastError= true)]
static extern intLogonUser(
String UserName, String Domain, String Password,
intLogonType, intLogonProvider, ref IntPtrToken);
public static void Main( ) {
IntPtrtoken = IntPtr.Zero;
intret = LogonUser(@" Bob", ".", "treasure", 2, 0, ref token)
if (ret = = 0) {
Console.WriteLine(" Error {0} occuredin LogonUser", Marshal.GetLastWin32Error( ));
return;
}
WindowsIdentitywi= new WindowsIdentity( token);
WindowsImpersonationContextimpctx= wi.Impersonate( );
StreamWriterfile = new StreamWriter(" test.txt");
file.WriteLine(" Bob's test file.");
file.Close( );
impctx.Undo( );

Cryptography
• Using cryptography in any application that processes sensitive or valuable data.
• Encryption works on the basis that there is one piece of information that the attacker has not been able to acquire, known as the key. The key is used as part of the encryption process and is kept secret. Sender selects an encryption algorithm and uses the secret key to create the encrypted data. When Receive gets the encrypted text, the secret key is used to restore the confidential message so that he can read it.

Types of Encryption
• Some types of encryption require Sender and Receiver to know the key and are called symmetric encryption (because they share the same knowledge). The problem with symmetric encryption is that both parties need to agree on what the secret key will be before sending any messages.
• Another approach is to use asymmetric encryption, where only Receiver has to keep a secret. Receiver creates a special pair of keys, one of which is kept secret (known as the private key ) and one that is given out to anyone who wants to send a message (the public key ). Receiver can provide the Sender his public key openly, because he does not care if someone intercepts it.

Integrity
• Integrity becomes an issue when Sender wants to send a message to Receiver but is concerned that someone will tamper with the message and change the contents. In this case, Sender does not care if anyone can read the message —they only want to make sure that the Receiver can detect any changes.
• The solution to this problem is to use a “keyed” hash code, which uses the contents of the message and a secret key to create the hash code. The Attacker can still modify the message, but can no longer create a valid hash code, because they lack the key used to create the original code.
• Unless threat is able to discover the key, they will be unable to create hash codes that will fool Receiver.

Digital Signatures
The goal of authentication is to allow Receiver to establish that Sender is the author of a message. For our purposes, this means that the Sender should be able to create a "digital signature” for the message and that Receiver should be able to check the signature to ensure that it is valid.

• Digital signatures rely on asymmetric encryption techniques, although they are applied differently than we discussed earlier. Sender creates a pair of keys, one made public and one of which kept private. To sign the message, the Sender creates a cryptographic hash code of the message that is sent to Receiver, as discussed earlier. The sender then signs the hash code using the private key. This creates a digital signature that is unique to the combination of the document.
• When Receiver gets the message, they verify the signature using Senders public key. If the signature is valid, then Sender has “signed” the message, and the Receiver can assume that a threat has not forged the message.

Creating a hash
[assembly:SecurityPermission( SecurityAction.RequestMinimum, UnmanagedCode= true)]
public class WindowsImpersonationTest{
[DllImport(" advapi32. dll", SetLastError= true)]
static extern intLogonUser(
String UserName, String Domain, String Password,
intLogonType, intLogonProvider, ref IntPtrToken);
public static void Main( ) {
IntPtrtoken = IntPtr.Zero;
HashAlgorithmx_hash_alg= HashAlgorithm.Create(" MD5"); // byte[] x_hash_code= x_hash_alg.ComputeHash( x_message_data); foreach(byte x_bytein x_hash_code) {
Console.Write("{ 0:X2} ",
x_byte);