Get the BEST

Technologists, SharePoint Specialists, Legal Experts and BA's available. Contact me direct: or call 704-873-8846.

Search This Blog


Saturday, February 22, 2014

Installing Disk Cleanup without the Desktop Experience

Like many folks have found, the Windows Disk Cleanup utility is very handy indeed - particularly for those that have upgraded an OS. There are a lot of files left over that it can be difficult to remove. While a great utility, Microsoft has opted to install it as part of the Desktop Experience feature. This means that a whole boatload of stuff is installed that isn't needed on a server (handwriting, media tools, etc.). 

In the past, I like many of you have just accepted this - taking the bloatware for the good of the utility.

But no more!!

It turns out that the Disk Cleanup feature can be installed manually without the need for the Desktop Experience. To do this however requires that it be installed on a server to retrieve the necessary files. 

First, it is necessary to install the Desktop Experience on a server with the same OS as the target. Once installed, there are two files that must be retrieved (location depends on the OS) as follows:

Get the EXE file from here:
  • Windows Server 2008 R2 - 64-bit:
    • C:\Windows\winsxs\amd64_microsoft-windows-cleanmgr_31bf3856ad364e35_6.1.7600.16385_none_c9392808773cd7da\cleanmgr.exe
  • Windows 2012 64-bit:
    • C:\Windows\WinSxS\amd64_microsoft-windows-cleanmgr_31bf3856ad364e35_6.2.9200.16384_none_c60dddc5e750072a\cleanmgr.exe

Get the MUI from here:
  • Windows Server 2008 R2 - 64-bit:
    • C:\Windows\winsxs\amd64_microsoft-windows-cleanmgr.resources_31bf3856ad364e35_6.1.7600.16385_en-us_b9cb6194b257cc63\cleanmgr.exe.mui
  • Windows 2012 64-bit:
    • C:\Windows\WinSxS\amd64_microsoft-windows-cleanmgr.resources_31bf3856ad364e35_6.2.9200.16384_en-us_b6a01752226afbb3\cleanmgr.exe.mui

Copy these files to a server to the following locations:
  • Cleanmgr.exe should go in %systemroot%\System32
  • Cleanmgr.exe.mui should go in %systemroot%\System32\en-US

Where %systemroot% is typically c:\windows.

If desired, create a shortcut to %windir%\System32\Cleanmgr.exe and name it Disk Cleanup.

Problem Solved!!!

If you want to trust a download, here it is:

Tuesday, January 14, 2014

Slipstreaming SharePoint 2013 and SharePoint Cumulative Updates

As was true with SharePoint 2010, Microsoft is releasing Cumulative Updates (CU's) for 2013. A new CU is generally released about every 3 months. As has been confirmed, ONLY the latest CU needs to be applied EXCEPT for 2013. For 2013, there is a mandatory update for March 2013 (which includes February 13's updates). The latest CU cannot be installed without the March 2013 applied first.

As for the CU's themselves, be sure to check for any issues folks have encountered and follow a normal process of testing on a non-production farm first. As an example, the latest CU (December 2013) has a known side effect in that it breaks the Performance Point dashboard designer - so if you are using Performance Point, don't install that CU (install October instead).

The entire list can be found here:

At any rate, it's not a lot of fun to have to incorporate the CU's on multiple systems - particularly when there are more than one. As well, Microsoft is not very clear about what to apply when - as in do you do Foundation, then Server or just Server and do you run SharePoint Configuration update after or not?

To clear the air on at least 2013, it now appears that CU's should only be applied based on the product you are running. That is, if you are running Server, ONLY apply the Server update - if running Foundation, ONLY Foundation. This can save you some time as like many of  you, I have in the past implemented both just to be sure (and Microsoft is very vague on this).

As for running PSCONFIG or SharePoint Configuration after each, the answer is YES - do it every time.

If you choose to run each of the updates separately, be aware that the updates DO NOT ALWAYS upgrade everything. Case in point: When applying the March 2013 update, it does not update the Business Connectivity Server (BCS) - after the update is done, a message will appear in the Health Analyzer that the BCS/BDC Database is running in compatibility mode. To correct this, use the SharePoint 2013 Management Shell (i.e. PowerShell) and provision the database as follows:

(Get-SPDatabase | ?{$_.type -eq "Microsoft.SharePoint.BusinessData.SharedService.BdcServiceDatabase"}).Provision()

As for "Slipstreaming", the process works the same way as it did in 2010.

NOTE: At the time of this writing, I have confirmed that the March 2013 CU is the only update that can be used in the slipstream process - the December 2013 CU must be applied manually after.

There are a few steps involved to do this.

1) Download all of the cumulative updates from the site for your product but be SURE to keep them in separate folders. When 'extracted', Microsoft uses cute names (ubersts for example) that are either because the update is coming from Germany or someone bought a VW and likes the term and includes the KB numbers so it's impossible to know which comes from which date.

2) For each the CU's, extract them to a folder - so for example, create a folder called March13CU. Copy the update (an .EXE file) to that folder - if the update (like August) comes in the form of a self-extracting zip, use that to extract the EXE (and in some cases, .CAB files) into that folder.

3) Use PowerShell or the command prompt, set default to the folder (i.e. March13CU) then breakout the CU EXE into individual files using the extract method - to extract them to the same folder, the command would be:

<CU EXE Name> /extract:<folder to extract to>

So if the downloaded CU was called March13ServerCU.exe (or you wisely renamed it as so) and wanted to extract it to the folder March13CU (the same folder where the EXE is), the command would be:

March13ServerCU.exe /extract:.\

Alternately, to create a sub-folder, the command would be:

March13ServerCU.exe /extract:.\Mar13SrvCU

If you wanted to use a different drive/folder, it would be:

March13ServerCU.exe /extract:D:\Mar13SrvCU

4) Copy the SharePoint installation into a folder on the server.

5) Run the Prerequisite installer either using the Splash screen running Setup.cmd or using the prerequisiteinsaller.exe - either way be SURE TO right click and choose Run as administrator (do this for EVERYTHING relating to SP13).

6) After the Prerequisites are installed, there are additional patches that must be run:

    *   KB2554876 - The SharePoint parsing process crashes in Windows Server 2008 R2.  (
    *   KB2708075 - IIS 7.5 configurations are not updated when you use the ServerManager class to commit configuration changes.  (
    *   KB2472264 - You can't customize some TCP configurations by using the netsh command in Windows Server 2008 R2.  (
    *   KB2567680 - Vulnerability in Windows Client/Server Run-time subsystem could allow elevation of privilege.  (
    *   KB2759112 - Hotfix for the .NET Framework 4.5 that resolves an ASP.NET race condition issue in Windows Server 2008 R2. ( (download:

    *   KB2765317 - Hotfix for the .NET Framework 4.5 that resolves an ASP.NET race condition issue in Windows Server 2012. ( (download:

While running these updates, if you receive an error or message saying "Update not applicable", that's fine. The key one here is KB2759112 - you CANNOT run a slipstream installation unless this has been applied.

7) If you are running a VM, snapshot it at this time (this gives you a fallback if the installation doesn't work).

8) Prepare the slipstream installation by copying the extracted CU files into the installation folder called 'updates'. Be sure to copy them in order by date released, March, August, etc.

9) Run the SharePoint setup (on ONE SERVER ONLY) - the first step of this only installs the binaries. At the end, if it says "Compete" the update took - if it shows "Some updates were not applied" you are hosed and you need to start over or install the CU's manually. When complete, you can verify the version installed by going to the hive, c:\Program files\common files\microsoft shared\web server extensions\15\isapi then right clicking on Microsoft.SharePoint.dll and selecting properties then clicking the Details tab. You can validate the number either from the Microsoft site or Steve Chen's blog post:

If the first server went OK, copy the same installation folder to other servers to install there.

10) As a first time installation, running the SharePoint 2013 Configuration Wizard will apply the updates so PSConfig (or PSConfigUI) not needed.

Friday, January 3, 2014

Creating an SQL Server Database alias (For SharePoint and other applications)

Setting Up a SQL Alias

Setting up a SQL Alias enables the ‘masking’ of a SQL Server instance name (default or named) and port in use so an alternate name can be used for the connection to SQL by another server. Using an alias is much more convenient for any application since an alias can be easier to remember than a complex instance name (for example, MyAlias vs. W3A842SQL\ProductionInstance). It is also better for security (such as hiding the port in use) and for moving between environments like QA to Production – if the alias is consistent between environments (though the underlying name will be different), it enables development and workflows to be created against the alias meaning code and workflows don’t have to be altered.

Before setting up an SQL Alias, it is important that the account in use has permissions to connect to the SQL Server. If using this alias for SharePoint, this should be the SharePoint Farm Account – this account should have already been added to SQL Server and have rights to login to the server.

In terms of SharePoint, setting up an alias is VERY important since several services in SharePoint cannot handle the use of an instance name (including the ‘famed’ User Profile Service). While SharePoint does not prevent the use of a full instance name, the problems with the services will appear later and cannot be corrected after the fact.

Setting up an alias is done on each server that will access SQL Server (in many cases, it is useful to setup the Alias on the SQL Server itself) and is done using SQL Server Client Network Utility also known as the “cliconfg” command. This can found simply by searching for it or simply opening up a Command Prompt (using ‘Run as administrator’) and entering the command: cliconfg.exe.  The SQL Server Client Network Utility enables setup of the alias and specifics such as a non-standard port.

Once the utility is opened, the first thing to do is to enable Named Pipes and TCP/IP protocols. While some applications may not require both (i.e. Named Pipes), SharePoint does. Under Disabled protocols:, click to select each in the left window and click the Enable >> button – this moves them over to the right window (Enabled protocols by order:):

In the Enabled protocols by order: window, click on TCP/IP then click the green arrow to move it to the top spot as shown (this makes TCP/IP the preferred connection):

Next click the Alias tab and click the Add… button:

Next add the connection using the steps shown below:

Note that the Alias name used can be any name however SPSQL is quick to remember. Click OK to save the changes and the entry will be shown:

Note that the connection parameters can be seen – the above indicating an instance name of SICGT1SQL using port 1433. Click Apply then OK to close.

Testing the Alias

Validate the SQL connection works by opening Start > Administrative Tools then clicking on ODBC Data Sources (64-bit). Click the System DSN tab then click the Add button:

On the Create New Data Source page, click the SQL Server default (see the version number as shown) – be aware that others may appear here:

On the Create a New Data Source to SQL Server page, enter the name (this can be anything) and specify the server as the alias name or the instance name (though alias should be used with SharePoint – per this example, shown as SPSQL):

On the next page, it will prompt for the security and client settings. By default ‘With Windows NT authentication using the network login ID.’ is selected – for most installations this will be correct.

Clicking the Client Configuration button will display the settings to be used – this should match what was entered using the cliconfg tool:

Be sure that ‘Dynamically determine port’ is NOT checked, click OK then click Next – this should bring up the next page indicating a successful connection:

If this does not show immediately, the connection will likely fail. Some troubleshooting tips here:
  1. Double check SQL Server accounts and be sure that the account in use (for SharePoint, the Farm Account) has been added with either DBO or DBCreator/Security Admin rights
  2. Verify that the account in use has a User Mapping to the Master database
  3. Verify that the firewalll has been disabled or the proper ports have been opened
  4. Ping the server to ensure that the IP Address is corect
  5. Double check spelling
  6. Double check SQL Confirmation for the IP and Port Number

If the connection works, click Next then on the next page, click Finish:

This displays the setup summary:

Click Test Data Source… and the Test Results page should appear:

This process should be repeated on each server.

Copying cliconfg Settings

As an alternate to the manual process of setting up the SQL Server alias on every server, it can be faster (and more accurate) to utilize the Registry key. Using ‘regedit’, the Registry key can be saved to a file and simply copied to then clicked on to apply it to each system.
NOTE: Do not do this unless all client connections will be the same across all servers. If there are additional aliases on the server, these will be included in the registry export.
To do this, open the registry editor (RegEdit.exe). Once opened, simply search for the SQL Alias name or navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client. Right click on the Client folder and select Export:

This pops up a window enabling the saving of the registry file:

To add this to another server, simply copy the file to a server, double click on the file and when prompted, click Yes to add it to the registry.

After adding the entry via the registry, it is necessary to verify the connection using the ODBC data connection (see Testing the Alias above).

Creating an Alias using SharePoint PowerShell

For SharePoint it is also possible to establish the SQL Alias using the Microsoft SharePoint (2010/2013) Management Shell. To use this, the account in use should have Administrator permissions to run PowerShell – right click on the SharePoint 2013 Management Shell (or 2010) and select Run as administrator.
If the standard SQL Port (1433) is used, the command format is simply:

Add-SQLAlias –AliasName <name to use> -SQLInstance <instance name>

If using a non-standard port, it is necessary to include it as so:

Add-SQLAlias –AliasName <name to use> -SQLInstance <instance name> -Port <port number>

  •  <name to use> is the name for the alias, for example SPSQL
  • <instance name> is the name of the SQL Instance, either the Server name or the instance name (Server\Name)
  •  <port number> is the port number assigned via the SQL Server Configuration Manager

As a few examples (assume the SQL Server name is “MySQLServer”):

·         Adding the default instance using Port 1433:
Add-SQLAlias –AliasName SPSQL –SQLInstance MySQLServer

·         Adding a named instance using Port 1433:
Add-SQLAlias –AliasName SPSQL –SQLInstance MySQLServer\MyInstanceName

·         Adding a named instance using Port 4900:
Add-SQLAlias –AliasName SPSQL –SQLInstance MySQLServer\MyInstanceName –Port 4900

After adding the entry via the Management Shell, it is necessary to verify the connection using the ODBC data connection (see Testing the Alias above).

Tuesday, December 24, 2013

Setting Distributed Cache Service Managed Account in SharePoint 2013

As many of you are aware, the Distributed Cache Service is a new feature for SharePoint 2013. In effect, this service is used primarily by the App Fabric service.

Once again, the Global Development Center gets it half right - while adding this service to SharePoint, they once again opt for a Powershell solution over enabling the setting like every other service.

For most, this will appear when a warning shows up in the Health Analyzer - by default, this service will be assigned to the Farm Account (hopefully) or if you followed the misguided method of using an Installation Account. Regardless, this account should be set to whatever you are using as a standard services account.

The following Powershell enables you to set this account (remember to start Powershell using 'Run as administrator'). Note that the -Identity set on the third line should be the service account to assign (note that the domain name must be specified AND verify that this account has 'Run as a service' rights!):

$farmRef = Get-SPFarm
$dCacheService = $farmRef.Services | where {$_.Name -eq "AppFabricCachingService"}
$acct = Get-SPManagedAccount -Identity sicgtmp\SPServiceAcct
$dCacheService.ProcessIdentity.CurrentIdentityType = "SpecificUser"
$dCacheService.ProcessIdentity.ManagedAccount = $acct

Be aware that when the .Deploy() command is executed be prepared to WAIT (and wait, and wait some more). This can take anywhere from a few minutes to 1/2 hour or more. Can't tell you why the delay nor why it varies so much.

For a quick reference on this, see the Technet article here:

Visual Studio Project Upgrade keeps popping up

I've seen a bunch of posts for this but hate having to search again when this occurs. The issue is simple: You open a Visual Studio 2010 in 2012 or 13 (or 2012 project in 2013) and the project prompts you to convert. Once done you'd think it's all set but no, when you close it and attempt to open the project again, it does another convert!

Since I hate searching for the fix myself when I forget what it was, here it is in all the glory:

   1) Open the project folder and locate the .csproj file

   2) Edit this in notepad and locate the FileUpgradeFlag tag - this will probably look something like this (note that the number may be different but 40 seems to be common):

   3) Simply remove the number here so that the line looks like:

   4) Save the file and close notepad (or whatever editor you used)

   5) Open the project again by double clicking on the Solution (.sln) file

Viola, project opens normally and does not prompt you to convert!

Sunday, December 15, 2013

Windows 2012 to Windows 2012 R2 - VMWare Workstation VMNet0 error

Discovered a problem while upgrading our VMWare Server from Windows 2012 to 2012 R2. On successfully updating, when starting up a Virtual Machine, got the error message that VMNet0 was missing. Once the VM booted, attempting to click 'Connect' on the network adapter in settings generated an error saying that the VMNet0 was not started.

Checking the VMWare settings (Edit > Virtual Network Editor...) I found that VMNet0 was indeed missing. Adding it proved a problem since it would not allow me to set it as Bridged (error that there were no non-bridged adapters available); in short, it was there, just not visible.

Did a bit of research and found some others had similar problems with Windows 8 to 8.1 - some recommended messing with the network adapter protocols (of which I do not recommend) but the best suggestion that worked overall was to simply re-load the installation media (or use the .exe if that's what you have) and run the VMWare Install Repair (you do not have to uninstall/reinstall). After the repair is complete, do a reboot of the server.

When the server has started up completely, open the VMWare console and check the network (Edit > Virtual Network Editor...) and VMNet0 (set as auto-bridged) should be displayed. Power up the VM and the network should appear as normal.

Saturday, November 30, 2013

Moving SharePoint IIS Sites Off of the System Drive

As you may be aware, SharePoint always installs sites on the C (system) drive by default. While this is fine for a development system, this is obviously not what is desired in a production environment.

There are multiple posts on how to do this but kudos to Jeremy Taylor - his post covers it all:

A few things to note about this:
  1. The Drives must match on ALL systems that will host IIS - this means the Web Front Ends (WFE's), the Application Servers and the Search Servers - the SAME drive letter must be used for all servers.
  2. Go ahead and follow the installation up to creating the Central Administration site.
  3. If this is a VM, take a SNAPSHOT BEFORE you do this!
  4. Run the command/batch script to move the IIS sites to a new drive - use the Command Prompt and select Run as administrator (NOTE: Moving IIS sites before or after the creation of Central Administration doesn't matter - the SharePoint install has the c: drive hardcoded and you can change it until after the fact).
  5. After IIS sites have been moved, use the PowerShell script to move Central Administration; open the SharePoint 2013 Command Shell and be sure to select Run as administrator.
  6. After running the PowerShell script, you MUST change the CA directory manually in IIS (see image below)
  7. Once this has been completed, be SURE to run an IISRESET (use the Command Prompt selecting Run as administrator)
  8. Verify that Central Administration is working,
  9. Run the Move IIS script on ALL other servers that will be hosting IIS.

Again note - if you are using Virtual Machines, perform a snaptshot before performing any of these steps!!

In case you have difficulty getting to the post, I've included the scripts here - remember that MOVE_IIS_ROOT.bat must be run on EVERY server hosting IIS and map to the SAME DRIVE!

To run both scripts, you MUST be sure that you use 'Run as administrator' - this is good habit for anything having to do with SharePoint 2013! 

Running the PowerShell script is only required on servers that will host Central Administration.



@echo off
IF "%1" == "" goto err
set MOVETO=%1:\

REM simple error handling if drive does not exist or argument is wrong 

REM Backup IIS config before we start changing config to point to the new path
%windir%\system32\inetsrv\appcmd add backup beforeRootMove

REM Stop all IIS services
iisreset /stop

REM Copy all content 
REM /O - copy ACLs
REM /E - copy sub directories including empty ones
REM /I - assume destination is a directory
REM /Q - quiet

REM echo on, because user will be prompted if content already exists.
echo on
xcopy %systemdrive%\inetpub %MOVETO%inetpub /O /E /I /Q
@echo off
REM Move AppPool isolation directory 
reg add HKLM\System\CurrentControlSet\Services\WAS\Parameters /v ConfigIsolationPath /t REG_SZ /d %MOVETO%inetpub\temp\appPools /f

REM Move logfile directories
%windir%\system32\inetsrv\appcmd set config -section:system.applicationHost/sites"%MOVETO%inetpub\logs\FailedReqLogFiles"
%windir%\system32\inetsrv\appcmd set config -section:system.applicationHost/sites"%MOVETO%inetpub\logs\logfiles"
%windir%\system32\inetsrv\appcmd set config -section:system.applicationHost/log"%MOVETO%inetpub\logs\logfiles"
%windir%\system32\inetsrv\appcmd set config -section:system.applicationHost/log"%MOVETO%inetpub\logs\logfiles"

REM Move config history location, temporary files, the path for the Default Web Site and the custom error locations
%windir%\system32\inetsrv\appcmd set config -section:system.applicationhost/configHistory -path:%MOVETO%inetpub\history
%windir%\system32\inetsrv\appcmd set config -section:system.webServer/asp -cache.disktemplateCacheDirectory:"%MOVETO%inetpub\temp\ASP Compiled Templates"
%windir%\system32\inetsrv\appcmd set config -section:system.webServer/httpCompression -directory:"%MOVETO%inetpub\temp\IIS Temporary Compressed Files"
%windir%\system32\inetsrv\appcmd set vdir "Default Web Site/" -physicalPath:%MOVETO%inetpub\wwwroot
%windir%\system32\inetsrv\appcmd set config -section:httpErrors /[statusCode='401'].prefixLanguageFilePath:%MOVETO%inetpub\custerr
%windir%\system32\inetsrv\appcmd set config -section:httpErrors /[statusCode='403'].prefixLanguageFilePath:%MOVETO%inetpub\custerr
%windir%\system32\inetsrv\appcmd set config -section:httpErrors /[statusCode='404'].prefixLanguageFilePath:%MOVETO%inetpub\custerr
%windir%\system32\inetsrv\appcmd set config -section:httpErrors /[statusCode='405'].prefixLanguageFilePath:%MOVETO%inetpub\custerr
%windir%\system32\inetsrv\appcmd set config -section:httpErrors /[statusCode='406'].prefixLanguageFilePath:%MOVETO%inetpub\custerr
%windir%\system32\inetsrv\appcmd set config -section:httpErrors /[statusCode='412'].prefixLanguageFilePath:%MOVETO%inetpub\custerr
%windir%\system32\inetsrv\appcmd set config -section:httpErrors /[statusCode='500'].prefixLanguageFilePath:%MOVETO%inetpub\custerr
%windir%\system32\inetsrv\appcmd set config -section:httpErrors /[statusCode='501'].prefixLanguageFilePath:%MOVETO%inetpub\custerr
%windir%\system32\inetsrv\appcmd set config -section:httpErrors /[statusCode='502'].prefixLanguageFilePath:%MOVETO%inetpub\custerr

REM Make sure Service Pack and Hotfix Installers know where the IIS root directories are
reg add HKLM\Software\Microsoft\inetstp /v PathWWWRoot /t REG_SZ /d %mOVETO%inetpub\wwwroot /f 
reg add HKLM\Software\Microsoft\inetstp /v PathFTPRoot /t REG_SZ /d %MOVETO%inetpub\ftproot /f
REM Do the same for x64 directories
if not "%ProgramFiles(x86)%" == "" reg add HKLM\Software\Wow6432Node\Microsoft\inetstp /v PathWWWRoot /t REG_EXPAND_SZ /d %MOVETO%inetpub\wwwroot /f 
if not "%ProgramFiles(x86)%" == "" reg add HKLM\Software\Wow6432Node\Microsoft\inetstp /v PathFTPRoot /t REG_EXPAND_SZ /d %MOVETO%inetpub\ftproot /f

REM Restart all IIS services
iisreset /start
echo ===============================================================================
echo Moved IIS7 root directory from %systemdrive%\ to %MOVETO%.
echo Please verify if the move worked. If so you can delete the %systemdrive%\inetpub directory.
echo If something went wrong you can restore the old settings via 
echo     "APPCMD restore backup beforeRootMove" 
echo and 
echo     "REG delete HKLM\System\CurrentControlSet\Services\WAS\Parameters\ConfigIsolationPath"
echo You also have to reset the PathWWWRoot and PathFTPRoot registry values
echo in HKEY_LOCAL_MACHINE\Software\Microsoft\InetStp.
echo ===============================================================================
goto success

REM error message if no argument or drive does not exist
echo New root drive letter required. 
echo Here an example how to move the IIS root to the F:\ drive:



Add-PsSnapin Microsoft.SharePoint.PowerShell -erroraction SilentlyContinue

$CentralAdminURL = Read-Host "Enter the Central Admin URL"

$CANewVirtualDirectory = Read-Host "Enter the new virtual directory you want to change it to"

$CASite = new-object Microsoft.SharePoint.SPSite($CentralAdminURL)
$CAWebApp = $CASite.WebApplication
$VirtualDirectory = $CAWebApp.IisSettings[[Microsoft.SharePoint.Administration.SPUrlZone]::Default]

Write-host Your current virtual directory for $CentralAdminURL is $VirtualDirectory.Path
Write-host This will be set to $CANewVirtualDirectory

Write-Host "Press any key to continue..."
$x = $host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown")

xcopy $VirtualDirectory.Path $CANewVirtualDirectory /I /E /H /O /X /K
$VirtualDirectory.Path = $CANewVirtualDirectory

Write-Host -fore green Success!! 
Write-Host IMPORTANT: -back blue Your virtual directory for $CentralAdminURL has been copied and updated in the Config Database. Please update IIS and point the Central Admin web site to the new virtual directory ($CANewVirtualDirectory). You would need to do an IISRESET on your Central Admin server and youre done!


Write-Host "Press any key to exit..."
$x = $host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown")