Scripting

ORIGINAL: hujirong

The .msi files has been created by the build process. The production deployment team is now asking for more automation and improvement. Here are the steps I see from the deployment instruction document (I put it here to give more info):

. Remove <product> web service in Add/Remove Programs
. Check if ceartain components have been removed from the Component Services.
. Execute the <product>.msi (user complains about no status provided during the installation, what shall I
do to add that? )

Look up dialogs and command lines with which you can fine tune the amount of progress presented to the installer. Place to find: msi.chm



. Create some folder in C:\Temp, and grand permission to some users

stupid, why do this?



. Ensure installed <product> is using ASP.Net 2.0
. Configure <product> to using particular application pool in IIS 6.
. Configure <product> web site directory security to use a particular identity.


can probably be done with appsearch


And also there are BizTalk installations:
. Export current binding
. Stop integration orchestration
. Unenlist integrations
. Undeploy and unbinding
. remove integration
. deploy


Find out what each of these things does and put them in your MSI or transform



The deployment team is also asking to provide
1. The .msi file with an "Answer File" so the deployment can be done unattended, and
2. A batch file to automate the above steps.



1. No need for an answer file to do unattended installs, google command line windows installer
2. see above, msiexec /i etc. etc.



Which type of scripting you normally use for this job? WScript? VBScript?
Thanks a lot.


Which job, customization of the packaging or deployment? For deployment I actually prefer SMS but VBS will do in a pinch, look into a delimited text file with workstation names, there's a lot of sample code out there.
Wscript is just a subset of vbscript, BTW
You're welcome

Thank you so much for your reply. I just joined as a SCM guy but asked to do this deployment automation, not really my domain. I answers to your questions and more questions are in-line, please read.


. Create some folder in C:\Temp, and grand permission to some users

stupid, why do this?
This is in the document, seems to store trace files:

Create and share the SFS.Assessment.WebService folder in c:\temp and the following folders if they are missing:

c:\temp\SFS.Assessment.WebService\OnlineTraceLogs
c:\temp\SFS.Assessment.WebService\OnlineTraceLogs\2007
c:\temp\SFS.Assessment.WebService\OnlineTraceLogs\2008


The deployment team is also asking to provide
1. The .msi file with an "Answer File" so the deployment can be done unattended, and
2. A batch file to automate the above steps.

1. No need for an answer file to do unattended installs, google command line windows installer
2. see above, msiexec /i etc. etc.

Which type of scripting you normally use for this job? WScript? VBScript?
Thanks a lot.

Which job, customization of the packaging or deployment? For deployment I actually prefer SMS but VBS will do in a pinch, look into a delimited text file with workstation names, there's a lot of sample code out there.
Wscript is just a subset of vbscript, BTW
You're welcome


They want me to automate the deployment, automate everything ideally, just run one batch file to deployment the application. Is SMS (http://technet.microsoft.com/en-us/library/cc181647.aspx) easy to start with?

Thanks again.
Jirong

. Create some folder in C:\Temp, and grand permission to some users

stupid, why do this?




This is in the document, seems to store trace files:

Create and share the SFS.Assessment.WebService folder in c:\temp and the following folders if they are missing:

c:\temp\SFS.Assessment.WebService\OnlineTraceLogs
c:\temp\SFS.Assessment.WebService\OnlineTraceLogs\2007
c:\temp\SFS.Assessment.WebService\OnlineTraceLogs\2008


makes no sense to store stuff there, and temp is supposed to be r/o to everyone, should be no need to add permissions. And no, SMS isn't something you just pull out of the box and start playing with to answer your later question. If you're dealing with a small enterprise, vbscripts will probably do OK to deploy. See my earlier posts re host names txt file etc. You've got a lot of reading to do -- good luck!

Thanks a lot, ask you something else.

We have a <product>.msi file installs, have a progress bar going, then exit without giving a proper successful status screen. Below is the MSBuild task to create the .msi file. How can I add a comfirmation screen?

<Target Name="Link Wix">
<ItemGroup>
<WixObject Include="$(IntermediateOutputPath)\*.wixobj" />
</ItemGroup>
<Light ObjectFiles="@(WixObject)" OutputFile="$(MsiDir)\$(SolutionName) $(VersionNumber).$(Configuration).msi" ToolPath="$(WixPath)" Extensions="$(WixPath)\WixIIsExtension.dll;$(WixPath)\WixUtilExtension.dll" Cultures="en-us" />
<Copy SourceFiles="$(MsiDir)\$(SolutionName) $(VersionNumber).$(Configuration).msi" DestinationFiles="$(MsiDir)\$(SolutionName).$(Configuration).msi" OverwriteReadOnlyFiles="true" />
</Target>

This is where actual .wxs file got created. I guess I need to add a GUIRef here, but how? Looks this is a customized task.

<UsingTask AssemblyFile="$(MSBuildProjectDirectory)\SFS.Msbuild.Targets.exe" TaskName="WxsTask" />
<UsingTask AssemblyFile="$(MSBuildProjectDirectory)\SFS.Msbuild.Targets.exe" TaskName="WxsFlattenTreeTask" />

<Target Name="CreateWxsFiles">
<Message Text="SolutionPath\SolutionName = $(SolutionPath)\$(SolutionName)"/>
<WxsFlattenTreeTask
SourceDirectory="$(SolutionPath)\..\deploy;$(SFSDLLsPath)"
OutputDirectory="$(OutputDirectory)"
DirRefName="SFSAEWSbin"
FileExcludePattern=".+\.dll\..+"
FolderExcludePattern="ReferenceData"
PreferredSourceFolder="$(SFSDLLsPath)"
/>
<WxsTask
SourceDirectory="$(SolutionPath)\..\deploy\ReferenceData"
OutputDirectory="$(OutputDirectory)"
DirRefName="SFSAEWSRef"
FileExcludePattern="1"
FolderExcludePattern="1"
/>
<WxsTask
SourceDirectory="$(SolutionPath)\$(ProjectName)"
OutputDirectory="$(OutputDirectory)"
DirRefName="SFSAEWS"
FileExcludePattern=".*\.cs"
FolderExcludePattern=".*"
/>
</Target>

Remove <product> web service in Add/Remove Programs You can control how, or whether an app appears in ARP or not using the public properties prefixed with 'ARP', e.g., ARPNOMODIFY. I suspect you may want ARPSYSTEMCOMPONENT. Look those up in MSDN.

How can I add a comfirmation screen?If you're going to script the installation, you can use the WindowsInstaller.Installer object's 'ProductState' property to determine the installed state. MSDN has the details on its use. Once the install script completes, you can MsgBox/WScript.Echo using the determined state.

-I guess I need to add a GUIRef here, but how? If you know XML, you could use the MS XML object model natively but it's a bit labyrinthine, to say the least. There's a component (free, I think) which provides a friendlier interface to XML for script from Chilcat/Chilkat.

- Components can be removed in script, certainly. I can't recall the object name you need to use, though. It may come to me in time.

The IIS app pool stuff can be done using WMI against the 'IIsWebVirtualDirSetting' and 'IIsApplicationPoolSetting' namespaces. Some of the code samples on MSDN are suspect. However, using them as a base, I just created a script for a colleague to create a VD and AP but as yet it's untested - I have no more space for VMs and he hasn't yet built his VM host - but you're more than welcome to what I have, if you think it might help.

- When you say "Ensure installed <product> is using ASP.Net 2.0 " presumably you mean you want to automate the section in IIS set up where you would select a site, click 'Properties', select the 'ASP.NET' tab and then select the relevant version? if so, the script I mention above has that functionality.

- IIRC, BizTalk has an Automation Interface. I seem to remember looking into it when I was working for a software house who were looking to build their BT servers in a similar automated way. Again, MSDN will tell all. As a starter, though, Google for 'WMI BizTalk'. Some cracking code to be found in the first few hits.

It's your choice whether or not you want the functionality of the various scripts (or single script) inside your MSI or not. There are arguments for and against.

- I agree with Owen. Leave C:\TEMP alone. Use the user's own %TEMP% folder. If the app insists, get it re-written. Seriously! Any vendor still doing this cr@p in 2009 deserves to wither and die. Or be killed.

Is SMS easy to start with? Er, didn't you say that you just joined as an SCM guy? [Presumably you meant 'SCCM', which is what MS is calling SMS this week - when it's not calling it 'CM/Config Manager/ConfigMgr']

- Forget using a batch file, other than purely as a launcher for your VBScript. Having said that, you can pass the entire command line required in a SCCM Package's Program.

You may want to look at PowerShell, a "technology" which I am slowly trying to migrate my scripts to. However, much of what you want probably already exists in VBScript form somewhere. It's a question of finding code fragments and editing/adding them to your script.

Maybe the below can give you some ideas as it's build on WiX:

Windows Media Center Application Step by Step
http://ajp-poncelet.net/Dnn/LinkClick.aspx?fileticket=ppvndRq1VBw%3D&tabid=63