Using PowerShell to Remove a DLL from the GAC on Windows Server 2008 R2 / Windows Server 2012

In my previous post (Using PowerShell to deploy DLLs to the GAC...) I showed a script on how to deploy a DLL to the GAC. In some cases we also want to remove DLL's from the GAC we do this we use the same assembly System.EnterpriseServices, as we used to deploy the DLL.

In the assembly  System.EnterpriseServices in the namespace System.EnterpriseServices.Internal  we have the class Publish. The Publish class contains a method named GacRemove which takes a string as an input parameter. This string is full path to the location where the original DLL is located. If you deleted the DLL you will have to copy it from the GAC to the original location and then execute GacRemove. Reference to MSDN

The following script is the absolute bare bone script needed to remove a DLL from the GAC. Remember to replace the <FULLPATH_TO_YOUR_ORIGINAL_DLL> with the actual literal path to the original DLL.

$AssemblyFilePath = "<FULLPATH_TO_YOUR_ORIGINAL_DLL>"
[System.Reflection.Assembly]::LoadWithPartialName("System.EnterpriseServices")
$publish = New-Object System.EnterpriseServices.Internal.Publish
$publish.GacRemove($AssemblyFilePath)
Write-Host “Assembly has been removed from the GAC”

Using PowerShell to deploy DLLs to the GAC on Windows Server 2008 R2 / Windows Server 2012

If you have a local development machine they you can usually drag and drop DLL's to the Assembly folder or if .Net Framework is installed use GacUtil to deploy DLL's. However these options are not normally available in a production environment. Best practices also dictates that GacUtil should not be located on a production environment as it is part of development tools.

One workaround is to turn off UAC for the current user so they can do a drag and drop to the Assembly folder in windows. I don't think turning off UAC in a production environment is a good option as it requires a server restart and it also open up the server for possible attacks even if it is only for a short while.

So if you have DLL's that needs to be deployed to the GAC and it is not handled by an installation package. Then I would suggest that you use PowerShell to call the built in functionality in the .Net Framwork to deploy the DLL.
.Net contains the assembly System.EnterpriseServices, in this assembly in the namespace System.EnterpriseServices.Internal  we have the class Publish. The Publish class contains a method named GacInstall that takes an input parameter of type string that should be the full path to the DLL-file that you want to install in the GAC. Reference to MSDN

The following script is the absolute bare bone script needed to deploy a DLL to the GAC. Remember to replace the <FULLPATH_TO_YOUR_DLL> with the actual literal path to your DLL.

$AssemblyFilePath = "<FULLPATH_TO_YOUR_DLL>"
[System.Reflection.Assembly]::LoadWithPartialName("System.EnterpriseServices")
$publish = New-Object System.EnterpriseServices.Internal.Publish
$publish.GacInstall($AssemblyFilePath)
Write-Host “Assembly installed in the GAC”

Nintex Workflows 2010 Web service calls and Load Balancing and get Aunauthorized access error

Issue

If you are using Nintex Workflows 2010 in your SharePoint Farm that is load balanced, and want to use the Web Service call action and you are using NTLM authentication. And you receive 401: Unauthorized errors when try to run the Call Web Service action, and you have verified that the account and password you are using is ok with doing the call. Then the reason is most likely a NTLM double-hop issue. Described in short you have already authenticated with your client credentials however NTLM does not permit a server to continue to use your credentials to authenticate on other servers so at the next hop (the Web Service call) the client credentials will no longer be valid. Googling for NTLM double-hop will give you a lot of links where you can read more about the subject.

Solution

• For Development, Deactivate Windows Loopback check on your front ends servers.
• For Production, Add an entry in windows registry for BackConnectionHostNames.
• Reconfigure your Host-files so that the Load balanced URL points to the local servers external IP address. 

Deactivate the loopback check in Windows 2008 R2

1. Click Start, click Run, type regedit and then click OK.
2. In Registry Editor located and then click the following registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
3. Right-click Lsa, point to New, and then click DWORD 32bit Value. Type DisableLoopbackCheck and then press Enter.
4. Right-click DisableLoopbackCheck, and then click Modify, in the Value data box type 1 and then click OK.
5. Quit Registry Editor and you might need to restart the server for the changes to take effect.

Add an Entry to BackConnectionHostNames

1. Start Regedit on the server
2. Navigate to the following registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
3. Right-click on MSV1_0, point to New, and then click Multi-String Value.
4. In the Name column, type BackConnectionHostNames and then press ENTER.
5. Right-Click BackConnectionHostNames and then press ENTER.
6. In the Value data box, enter the FQDN for the you're using to access your SharePoint site. If you have multiple hostnames then each one has to be entered on a new line like this:
www.mysite.com
www2.mysite.com
intra.mysite.com
7. Close Regedit and restart your server.

Note: If BackConnectionHostNames exists as a REG_DWORD you will have to delete it first and recreate it as a Multi-String value as in step 3.

Add an entry to the servers Host-file 

Navigate to you server Host-file and make an entry that looks like this
127.0.0.1            < FQDN for you NLB >
Save an close the file. (If you cannot edit the host file in the etc folder. You might need to make a copy to the desktop and make the changes then copy it back.)

Repeat this on all server and you should be good to go.
  

  

Adding user to SharePoint_Shell_Access role

When you want to do something with SharePoint PowerShell you first have to add you user to the SharePoint_Shell_Access roll. To do that you have to run the command Add-SPShellAdmin from the SharePoint 2010 Administration Shell. This can be found on the same place as your Central Administration link in the start menu.

To add you user to the SharePoint_Shell_Access role run this command: Add-SPShellAdmin -Identity [Domain \Username] 

This will add your user to the SharePoint_Shell_Access role in the farm configuration database and ensure that your in the WSS_Admin_WPG local group on all the servers in the farm.

This is the absolute simplest way of adding a user to the SharePoint_Shell_Access role. But for a more granular control you can specify which content database the user should have this roll on.

For a complete listing of the commands please check on this link: Add-SPShellAdmin@Technet