AutoSpInstaller with SCCM

Jan 13, 2012 at 7:35 AM

Good morning,

We're having a blast at trying to get SCCM to run the automatic installer. Our first attempt showed this errorlog:

**********************
Windows PowerShell Transcript Start
Start time: 20120112160127
Username  : Contoso\SYSTEM 
Machine	  : ACP-CONT01 (Microsoft Windows NT 6.1.7600.0) 
**********************
Transcript started, output file is C:\Logs\AutoSPInstaller-2012-01-12_16-01.rtf
-----------------------------------
| Automated SP2010 install script |
| Started on: 01/12/2012 16:01:27 |
-----------------------------------
--------------------------------------------------------------
 - Validating user accounts and passwords...
 - Account "contoso\SysUsr-ShP-Adm-CentA-A"...Verified.
 - Account "contoso\SysUsr-ShP-apl-Prtl-A"...Verified.
 - Account "contoso\SysUsr-ShP-apl-Mysit-A"...Verified.
 - Account "contoso\SysUsr-ShP-Svc-Srch-A"...Verified.
 - Account "contoso\SysUsr-ShP-Svc-dflt-A"...Verified.
--------------------------------------------------------------
 - Testing access to SQL server/instance/alias: ACP-C001-V13\sharepoint
 - Trying to connect to "ACP-C001-V13\sharepoint"...Success
 - SQL Server version is: 10.50.1600.1
 - This instance of SQL Server is clustered
 - Check if BANK\A30-0381$ has dbcreator server role...Pass
 - Check if BANK\A30-0381$ has securityadmin server role...Pass
 - Check if BANK\A30-0381$ has sysadmin server role...Pass
--------------------------------------------------------------
 - Install based on: 
 - Z:\PRD000FA\SP2010_AutoSPInstaller\AutoSPInstaller\AutoSPInstallerInput-ACP-CONT01.xml 
 - Environment: Contoso.ACP 
 - Version: 2.5.1
--------------------------------------------------------------
 - Disabling Loopback Check...
--------------------------------------------------------------
--------------------------------------------------------------
 - Disabling IE Enhanced Security...
--------------------------------------------------------------
--------------------------------------------------------------
 - Setting services Spooler, AudioSrv and TabletInputService to Manual...
 - Spooler is already stopped and set Manual, no action required.
 - AudioSrv is already stopped and set Manual, no action required.
 - TabletInputService is already stopped and set Manual, no action required.
 - Setting unused services WerSvc to Disabled...
 - WerSvc is already stopped and disabled, no action required.
 - Finished disabling services.
--------------------------------------------------------------
--------------------------------------------------------------
 - Disabling Certificate Revocation List (CRL) check...
--------------------------------------------------------------
--------------------------------------------------------------
 - Installing Prerequisite Software:
 - Running Prerequisite Installer...
 - Error: 
--------------------------------------------------------------
Script aborted!
 - An unknown error occurred installing prerequisites
-----------------------------------
| Automated SP2010 install script |
| Started on: 01/12/2012 16:01:27 |
| Aborted:    01/12/2012 16:01:40 |
-----------------------------------
**********************
Windows PowerShell Transcript End
End time: 20120112160140
**********************

Seeing how the "prerequisites" part of the installer didn't give us back any error which we could handle, I edited the "AutpSPInstallerFunctions.ps1" file, commented line 330 (using a #)  and put in "Else {Throw "$_"}" on line 331.

After a re-run it gave out the following error:

Get-Item : Cannot bind argument to parameter 'Path' because it is an empty string.
At line:1 char:17
+ $bits = Get-Item <<<<  $dp0 | Split-Path -Parent
    + CategoryInfo          : InvalidData: (:) [Get-Item], ParameterBindingValidationException
    + FullyQualifiedErrorId : ParameterArgumentValidationErrorEmptyStringNotAllowed,Microsoft.PowerShell.Commands.GetI
   temCommand

After some digging I found out it's having these issues on the next line of codes:

$0 = $myInvocation.MyCommand.Definition
$dp0 = [System.IO.Path]::GetDirectoryName($0)
$bits = Get-Item $dp0 | Split-Path -Parent

When I try to execute the above commands in powershell.exe or powershell_ise.exe, running with my own user, it also gives me the error listed above.

Seeing how Z:\ is used to install SharePoint2010 via the scripts I'm going to attempt to put the $bits variable at a static directory and see if the installer script wants to run.

Unless perhaps someone else has some idea's on how to tackle this (small) issue?

Jan 17, 2012 at 8:45 AM

And I guess I spoke to soon :(

Getting the following error now for a few tries in a row...

--------------------------------------------------------------
--------------------------------------------------------------
- Disabling Certificate Revocation List (CRL) check...
--------------------------------------------------------------
--------------------------------------------------------------
- Installing Prerequisite Software:
- Running Prerequisite Installer...
** SPbits = Z:\PRD000FA\SP2010_AutoSPInstaller\AutoSPInstaller
** bits = Z:\PRD000FA
- Error: 
--------------------------------------------------------------
Script aborted!


Exception             : System.Management.Automation.RuntimeException:  This co
                        mmand cannot be executed due to the error: The system c
                        annot find the drive specified.
TargetObject          :  This command cannot be executed due to the error: The 
                        system cannot find the drive specified.
CategoryInfo          : OperationStopped: ( This command c...rive specified.:St
                        ring) [], RuntimeException
FullyQualifiedErrorId :  This command cannot be executed due to the error: The 
                        system cannot find the drive specified.
ErrorDetails          : 
InvocationInfo        : System.Management.Automation.InvocationInfo
PipelineIterationInfo : {}
PSMessageDetails      :
I'm guessing it doesn't understand Z:\ and where it goes to. I've had a small e-mail conversation with Brian about the "MyInvocation" command, in order to get the UNC path. Initially however this doesn't seem to work in my case as the value remains <NULL>. Are there any other thoughts how to put $SPbits on an UNC value? Of course I can define it statically, but that kind of defeats the purpose of having it automatically installed >.<

Jan 17, 2012 at 5:47 PM
Edited Jan 17, 2012 at 5:47 PM

And the problem is found.

PowerShell has an odd idea of reporting errors. The above mention error is about not being able to find the file specified in order to run it. Although it is true, the real issue was that the user running the script had no permission to go to the path specified (thus resulting in an access denied error) which in turn results in a file not found.

Coordinator
Jan 18, 2012 at 4:45 AM

Yes I think as a rule you want to stay away from mapped network drive letters, especially on remote servers. I always do installs over UNC hence how I discovered that $myInvocation.MyCommand.Definition works best. Note: this only works properly in the context of a running script; just typing $myInvocation.MyCommand.Definition in a console doesn't give you the same kind of result I find.

Anyhow instead of a drive letter, see if SCCM can do the install over a UNC path (which would exist regardless of the logged-on user, as opposed to a drive letter)...

Brian

Jan 18, 2012 at 5:45 AM
Rawh wrote:

And the problem is found.

PowerShell has an odd idea of reporting errors. The above mention error is about not being able to find the file specified in order to run it. Although it is true, the real issue was that the user running the script had no permission to go to the path specified (thus resulting in an access denied error) which in turn results in a file not found.

This makes more sense. I was going to ask you about the user running setup because it appears a non-domain user was running it. In any case, I *have* successfully used AutoSPInstaller with mapped drives, no problems :)

Jan 18, 2012 at 1:14 PM
brianlala wrote:

Yes I think as a rule you want to stay away from mapped network drive letters, especially on remote servers. I always do installs over UNC hence how I discovered that $myInvocation.MyCommand.Definition works best. Note: this only works properly in the context of a running script; just typing $myInvocation.MyCommand.Definition in a console doesn't give you the same kind of result I find.

Anyhow instead of a drive letter, see if SCCM can do the install over a UNC path (which would exist regardless of the logged-on user, as opposed to a drive letter)...

Brian

We are now using the UNCpath. I still had SCCM map the UNCpath to a driveletter because it SCCM otherwise does not tell the targetmachine from where the files that are being installed, are located.

SCCM maps Z:\ to the UNCpath. SCCM then starts automatically from that directory/drive when you run something from an advertisement.
The example I used to get the UNCpath from this is:

$currentDirectory = Get-Location
$currentDrive = Split-Path -qualifier $currentDirectory.Path
$currentFolder = (get-location).drive.currentlocation
$logicalDisk = Gwmi Win32_LogicalDisk -filter "DriveType = 4 AND DeviceID = '$currentDrive'"
$uncPath = $currentDirectory.Path.Replace($currentDrive, $logicalDisk.ProviderName)

$bits = $uncPath+$currentfolder
$SPbits = $bits+"\SharePoint"

Resulting in $bits with the value "\\Distrobution-servername\hiddendir$\sccmpackagecode\

From that part onward it started the installation successfully (started by calling the .bat script).

Although I'm still having quite a few other bumps on that road, I will dedicated a different topic / thread on that when the solution eludes me.

Mar 2, 2012 at 12:40 PM

Hi,

interesting threat! I'm currently working on something similar. We're using SCVMM2012 to deploy a whole farm from scratch including OS+SQL installation. Actually the pieces for SCCM are pretty much the same as in SCVMM - so if you'd like to share some knowledge let me know. I had some hard time getting a three server install running, especially UPS was tricky when AutoSPInstall is not run from within a user session but totally unattended.

Regards,