Complicated

[SPStuff]

Hi. Looks promising but just I spent an hour trying to understand how to make it work. I still can not make it work. I'm not a sql expert but I know my way around PowerShell and I know my way around automated installs. This tool would benefit from a single xml input config with all the neessary settings. Check out the AutoSPInstaller for SharePoint. That's more complicated and still uses on single xml file and does all the config file generating behind the scene based on what you are installing.
Here is How I see it:
Source folder => 2008-2012-2014-xxxx
Xml file to generate config (ini files) based on version and settings in this xml
Single powershell file to do the install and why not a function script to group all functions together
a batch file to start it all if you need some elevation of privilige.
Thanks for the effort.

[JasonCarter80]

I'd be happy to help fix any issues or explain any specific problems, but I don't see any of either listed. This project is being used in many large companies effectively every day and it works well. I installed 4 machines to standards in 1 hour total last week. It works, and it works well.

This project has been on going for over 5 years. While I am not the original developer I have chosen to maintain it. If you have specific recommendations as how to make it better without completely re-architecting the entire thing, I'd be happy to discuss those.

[SPStuff]

Hi Jason. Thanks for the quick reply. I don't doubt it working well. I usually do automated sql installs with an unattended file tuned to my SharePoint needs. I thought why not use available solutions. To tell you the truth this is the second time I try SQLSPade and I couldn't for the life of me make it work for me as quickly I'd expect from an automated script. I tried two other scripts and they did the job in 5 mn I was doing the install. I think the solution is over-complicated. Let me think about how to simplify things. I guess this will need some re-architecturing. I don’t know all the sql requirements as I only use sql for SharePoint but I really think the less scripts you have there the better. I’ll try something and get back to you with some refactoring tips.

[SqlTechMike]

I am the original creator of SPADE and would be happy to discuss with you why I made the design decisions that I did. That being said, I would like to clarify a few things...

SPADE does use a single xml configuration file (Run-Install.config) and all of the settings exist in that file. I spent a good deal of time refactoring my original scripts to centralize all of the options in that single file. If you have found a configuration outside that file that I have missed, please let us know so that we can correct it.

I chose to use separate script files for the Common, Pre, and Post scripts because the solution was intended to be modular. You can start using the tool as-is and then start adding your own scripts or customize what's there without having to make changes to the underlying framework. This makes changing the tool simpler as the scripts are clearly named. Also, in the case of pre and post scripts, the naming of the individual script files is what controls the order of operations...this is important because I can't create a table in a database that hasn't been created yet.

My intent for this tool was never to be up and running 5 minutes after download, it is designed to build a SQL instance to your organizations standards very quickly with minimal effort. To do that, you have to define what a standard build looks like. The project helps with that by providing a sample configuration file that can be customized as needed, but you still need to fill in some missing information.

I acknowledge that initial setup of the tool, and building out the required directory structure is the hardest part of using SPADE, which is why I created a winform app called SQLSPADE Helper that can build out the directory structure for you across multiple data centers. When you first started trying SPADE, did you review any of the documentation that steps you through the initial configuration and the execution? I would appreciate knowing if the documentation was too difficult to follow or maybe too hard to find.

[JasonCarter80]

I do like the single script idea, which I will be attempting, and I want to
simplify the settings file to some degree as there is alot of duplication
across the standard INI settings, but I don't see how I can get away from
it completely as we will always need to know where your files and
customizations are.

Best Regards,
Jason Carter
jason-carter.net

"A wise explorer learns more about television with a magnet than a couch."

• Unknown

On Tue, Nov 15, 2016 at 7:59 AM, SPStuff notifications@github.com wrote:

Hi Jason. Thanks for the quick reply. I don't doubt it working well. I
usually do automated sql installs with an unattended file tuned to my
SharePoint needs. I thought why not use available solutions. To tell you
the truth this is the second time I try SQLSPade and I couldn't for the
life of me make it work for me as quickly I'd expect from an automated
script. I tried two other scripts and they did the job in 5 mn I was doing
the install. I think the solution is over-complicated. Let me think about
how to simplify things. I guess this will need some re-architecturing. I
don’t know all the sql requirements as I only use sql for SharePoint but I
really think the less scripts you have there the better. I’ll try something
and get back to you with some refactoring tips.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#20 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAot97Zu2U02jY1K3qOutQXJa1vfyftzks5q-aylgaJpZM4KwzwG
.

[SPStuff]

Hi guys. Glad to see you're around and watching over your baby :-)
Here is a starter: I grouped all the common/pre/post scripts in one single file => SpadeCommonFunctions.ps1. Next step is to have a second script and a batch file.
So we end up having:
SpadeCommonFunctions.ps1
SpadeInstaller.ps1
Spadelauncher.cmd
A folder called SQL => inside it you have binary folders per version.
This is the design used by THE SharePoint installer available on codeplex.
Your batch starts the mains powershell script which calls the common functions and on you go.
You xml should have all the options possible with a Provision element for example. I want such an option = MyOption => Provision = true
So what does a new user have to do:
Sets the version in the xmlfile = version = 2014
Fill in the server name(s).
Fill in the account/password stuff
Set pre/postinstall options to true
Copy the Binaries to the corresponding version folder
Run the batch file
You can add a second functions script for custom functions like the AutoSPInstaller does for custom user functions.
Now the notion of Datacenter is overkill, I was wondering what that meant in the whole procedure when I first saw it. in fact you can just name it SourceFoder or Sources. You don't even have to name it if you pick it up based on the version set in the config xml file…
As for all the ini files, they can go into the xml too. And they can be chosen based on version.
Then again I'm not a Sql expert and all I need in sql is the database engine and sometimes ssas or ssrs but I was looking into automating my SharePoint labs and couldn't find something straightforward. I did use this script (http://www.sqltechnet.com/2014/02/powershell-script-for-sql-server.html) and this one (http://www.sqlhammer.com/automated-unattended-silent-sql-server-installs-with-powershell/). Both were easy to use.
I'm certainly missing a lot of things this tool was meant for. I'll give it some time in the future nd get back to you with my tweakings.

[SPStuff]

Mike, I tried to go through the documentation on codeplex. I didn't give it much time when I first tried. i thought downloading the tool and settings some values in an answer file would do it but then realised it was not working for me so I made my own ini file and fed it to the sql setup.exe. But still I find the design overkill for what it is supposed to do. I'm not arguing or complaining really, I just hoped I'd be up and running with my sql instance in a blast :-)

[SPStuff]

and one more change: convert the sql script files to powershell ones and integrate them to the commonfunctions file. you can use the native 2012+ invoke-sqlcmd or this one from https://blog.jourdant.me/post/simple-sql-in-powershell

[SPStuff]

An idea for the ini file options: you can have an xml node with all the options available for all sql versions and make them version dependant. you can set the option but it can be used only if sql version matches with the option version.

[SqlTechMike]

There seems to be a fundamental disagreement as to what the tool is "supposed to do". I built this over a period of time while working as a DBA in a large SQL Server environment, and every feature in there has a reason. The concept of DataCenter allows you to have copies of the binaries local to each data center or environment and all you have to do is specify a friendly name when kicking off the install. Since the list of paths is maintained in the XML file, you don't have to remember which path is used for which location. If you don't require that functionality then you only define a single location and you never have to update the value.

The XML file is designed to be initially configured and then rarely touched again. If you need to change a setting for a one-off build, then you simply override the setting by adding it to the Overrides hashtable in the Start-SqlSpade script.

As far as converting the SQL scripts to PowerShell...I don't understand why that is necessary. I appreciate that you are not a SQL Server specialist, but if you look at the code you'll see that SPADE is already doing what you've requested...picking up the SQL script and executing it from PowerShell. The tool was designed for SQL DBAs and there are tasks that need to be executed in T-SQL. Why would I ask somebody to take the extra step of wrapping a SQL statement in PowerShell when the tool is already capable of doing it for them. The modular approach that was taken is meant to make it easy to add pre/post tasks to the install process. I'm not sure why the push to convert everything and move it to a single script file when you aren't even the one copying the files over. You copy over the config file, 2 script files, and a batch file to the server you want to install on and SPADE handles moving everything else - the common scripts, the pre/post scripts, the install binaries, etc.

Please also note that moving all of the scripts to a single file will break the logic that selectively applies scripts based on the selected SQL version.

I appreciate all of the feedback and would love to help get this product to work for you, but I would hate to see it gutted and what I feel are important features removed because you don't think that it does what it's "supposed to do".

[JasonCarter80]

Adding all the 'Common' scripts into a single file makes sense, but
definitely not the pre and post scripts

On Tue, Nov 15, 2016, 1:30 PM SqlTechMike notifications@github.com wrote:

There seems to be a fundamental disagreement as to what the tool is
"supposed to do". I built this over a period of time while working as a DBA
in a large SQL Server environment, and every feature in there has a reason.
The concept of DataCenter allows you to have copies of the binaries local
to each data center or environment and all you have to do is specify a
friendly name when kicking off the install. Since the list of paths is
maintained in the XML file, you don't have to remember which path is used
for which location. If you don't require that functionality then you only
define a single location and you never have to update the value.

The XML file is designed to be initially configured and then rarely
touched again. If you need to change a setting for a one-off build, then
you simply override the setting by adding it to the Overrides hashtable in
the Start-SqlSpade script.

As far as converting the SQL scripts to PowerShell...I don't understand
why that is necessary. I appreciate that you are not a SQL Server
specialist, but if you look at the code you'll see that SPADE is already
doing what you've requested...picking up the SQL script and executing it
from PowerShell. The tool was designed for SQL DBAs and there are tasks
that need to be executed in T-SQL. Why would I ask somebody to take the
extra step of wrapping a SQL statement in PowerShell when the tool is
already capable of doing it for them. The modular approach that was taken
is meant to make it easy to add pre/post tasks to the install process. I'm
not sure why the push to convert everything and move it to a single script
file when you aren't even the one copying the files over. You copy over the
config file, 2 script files, and a batch file to the server you want to
install on and SPADE handles moving everything else - the common scripts,
the pre/post scripts, the install binaries, etc.

Please also note that moving all of the scripts to a single file will
break the logic that selectively applies scripts based on the selected SQL
version.

I appreciate all of the feedback and would love to help get this product
to work for you, but I would hate to see it gutted and what I feel are
important features removed because you don't think that it does what it's
"supposed to do".

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#20 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAot91Th7MItAhbhIwrlwcdIB0n8Y5WKks5q-fpKgaJpZM4KwzwG
.

Best Regards,

Jason Carter
813-516-5861

[SqlTechMike]

I'm not opposed to grouping the common functions into a single script, but I'm not sure what the benefit is? Maybe I'm just not understanding...are the separate files really causing an issue?

[JasonCarter80]

Portability for one. It also will also keep all central pieces together,
versioned if you will. There can exists a case where I have the
Installer.ps1 on the loca machine, when I execute it, it REDOWNLOADS all
the Common files from the remote location. If there has been an update to
the files on the remote location it could break, which I have seen.

A single file can also setup for the possibliy for a future one liner type
installer as well iex http://private.github.com/sqlspade.ps1

Best Regards,
Jason Carter
jason-carter.net

"A wise explorer learns more about television with a magnet than a couch."

• Unknown

On Tue, Nov 15, 2016 at 2:03 PM, SqlTechMike notifications@github.com
wrote:

I'm not opposed to grouping the common functions into a single script, but
I'm not sure what the benefit is? Maybe I'm just not understanding...are
the separate files really causing an issue?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#20 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAot9-0a1uqTP21XKt2Tqb4m_OE4hnJ8ks5q-gH2gaJpZM4KwzwG
.

[SPStuff]

yes.
Main installer script
Functions script
Custom functions script
Batch launcher
Binary folder
The idea of using the same scripting language is better in my opinion. just wrap your sql queries in powershell functions. logging will also benefit from this.
As for sequencing you can do all that in the main installer:

function prep
{
prep section:
function 1 (in the common or custom functions file)
function 2
function 3
}

Function Install
{
function 4
function 5
function 6
}
Function Post
{
function 4
function 5
function 6
}

of course running functions will have some conditions based on the provision flag of different option and so on..

this will make the flow of action and debugging tweaking improving much better.

Do take a look at this design here: https://autospinstaller.codeplex.com/
It is used to install different versions of sharepoint farms with pre/post config actions and you can even add additional pluggins or addins for sharepoint. single xml no ini files no nothing :-) it even installs updates, service packs, language packs. and you can tweak it to your liking. I'm not saying your tool is not doing the job. I'm just trying to make the next guy come, pick it up and modify 5/6 lines in the xml, run the batch file and go grab a coffee.

[SPStuff]

to go on a bit further:
Batch script runs the main script
Main script dotsources the common and custom functions, checks chosen/entered version in the xml script => 2012
Set source location as 2012 in the binary folder
Gets and validates all options available for version =
Script generates the ini file
Validates service accounts/sql components/target folders/drive cluster size all best practice OS stuff for SQL
Script rides on and sets all post actions at the end of the script.
this might be a good starting point.