[Martin Zugec]

Hello there!

I am working hard on SDS (currently build 0006) and I am looking for some developers that would like to help.

Who I need?

a.) someone to create GUI. I began with .NET, however I dont want to leave core developement.

b.) someone to help me with core - it is based on batches+FS...

c.) someone to write packages/plugins... This is quite simple and only requirement is to have good ideas.

EDIT:
d.) as client I am using kTool from Kenedy. So I would also invite someone with knowledge of AutoIt.

e.) heh, I almost forgot - if there is any volunteer to take care of documentation, it would be great

f.) I am looking for people who have ideas how to make SDS better solution...

Now some details about SDS - SDS is free&easy deployment solution... Right now it is functional, however I need to debug it a little before first public beta test.

Please, help me if you can... I think this could be useful for many administrators (not for me, I am using USD )

This post has been edited by Martin Zugec: 13 September 2005 - 07:43 AM

[phkninja]

Is the project currently running with command line. I have no problem creating a GUI for a command line program (just need to know the switches and a graphic of the layout concept would be nice). I can send you a program or two I have written with GUI's.

I use a C++ library called wxWigets (used to be wxWindows). This is a cross compatible C++ library that is free to use, and is also easy to use.

[Martin Zugec]

2phkninja: That would be great! Could you please upload it somewhere (I got quite aggressive AV protection )...

You dont need to cooperate with command line - just "import" the directory structure...

My ICQ is 137412582, pls contact me directly, I will explain further...

[Martin Zugec]

Following informations are for developers. It is basic of SDS implementation.

SDS
--------------------------------------------------------------------------------------------
Main component is SDSAutomatic.cmd (a.k.a. SDSA). It is scheduled task running every minute.

SDS parse Jobs\Regular directory and check every subdirectory.
The subdirectories uses syntax JobState.JobName.
If JobState is equal to Running, SDSA enter this directory, import settings from file Job.ini and then enter subdirectory ComputerGroups.
Here it parses through all available files. That files represents computers and have extension .sds. For example pc1000.sds represents computer pc1000.
For every file/computer SDSA tries to check if computer is available (ping), if it is available, SDSA will copy SDSClient.exe to computer + ini file generated from job.ini.
Now it activate remote computer - schedule/psexec etc the execution of SDSClient.exe with .ini file as parameter.

Now lets talk about Job.ini. This file contains informations about job.

It contains following settings:
Operation=Installation\Command\Group
Package=%packagename%
Storage=Remote\local (currently only Remote supported)
InstallationMethod=RunOnceEx\PsExec\Scheduled
Restart=No\Yes (available only for RunOnceEx installation method)
AllowDefaultPackages=Yes\No

Operation - defines operation type. Installations/Commands are the same, they are just divided because they are in different location. Groups are combination of commands/installations.
For example group DotNET_Framework consist of Installation=DotNET_Framework_1.1 and Installation=DotNET_Framework_1.1_SP1.
For installation/command you must create file Package.ini. I will describe syntax later. For Groups you must create file Group.ini with syntax
OperationType=Package.

Package - defines the name of package. For example Office20003. This is the name of directory, so SDSA will try to find %PackageDirectory%\%OperationType%\Office2003\Package.ini.
If operation type is installation/command, it will try to find package.ini, for group it will try to find Group.ini.

Storage - not implemented yet, always set to Remote.

InstallationMethod - defines method that will be used to activate SDSClient on remote computer.

Restart - only available to RunOnceEx installation method. When ROE entries are created, SDS will automatically restart computer, so you dont need to wait till user logoff/logon.

AllowDefaultPackages - default packages are created for every job. For example if you want to create some log files, you create default package. They are acting as plugins. They are defined in Main.ini.
This setting means if default packages from main.ini are allowed or not.

For syntax of Package.ini see kTool documentation:
http://www.msfn.org/...showtopic=28393

You are defining global behavior by two configuration files: Main.ini and Paths.ini

Main.ini

; Name of the package file, that MUST be in every installation/command directory
SDS.Global.PackageFile=Package.ini

; Name of the administrator account
Secret.AdministratorAccount=uainstall

; Administrator password
Secret.AdministratorPassword=uainstall*pass

; Domain - used for autologon
SDS.Global.Domain=!UserDomain!

; How long till scheduled task will be executed on target computer. Default is 3 minutes
SDS.Global.ScheduledTimeout=1

; Default setting for remote storage - only Remote available yet, I need to work on it
SDS.Global.Parameter.DestinationStorage=Remote

; Method that should be used to deploy packages
SDS.Global.Parameter.InstallationMethod=Scheduled

; AutoRestart - this means if computer should be automatically restarted after RunOnceEx entries are created
SDS.Global.Parameter.Restart=No

; Defined if default packages should be included
SDS.Global.Parameter.DefaultPackages=Yes

; Default packages - Start. Syntax is SDS.Global.DefaultPackages.Start.%Number_of_Package%=%OperationType%:%Package_Name%
SDS.Global.DefaultPackages.Start.1=Command:Minimize_Command_Line
SDS.Global.DefaultPackages.Start.2=Command:Disable_RemoteRegistry
SDS.Global.DefaultPackages.Start.3=Command:Disable_Input

; Default packages - End. Syntax is SDS.Global.DefaultPackages.End.%Number_of_Package%=%OperationType%:%Package_Name%
; SDS.Global.DefaultPackages.End.1=Command:Disable_AutoLogon
SDS.Global.DefaultPackages.End.2=Command:Enable_RemoteRegistry
SDS.Global.DefaultPackages.End.3=Command:Enable_Input
SDS.Global.DefaultPackages.End.4=Command:Restart_Computer

Paths.ini

; General path to the package directory. You should store Commands/Installations/Groups folders inside this one (but you dont have to.
SDS.Path.PackagesStore=\\!ComputerName!\PackageStore

; Path to the installations directory. Here are stored installations for applications
SDS.Path.InstallationsStore=!SDS.Path.PackagesStore!\Installations

; Path to the logs directory
SDS.Path.LogsStore=\\!SDS.Path.ExecutionPath!\Logs

; Path to the commands directory
SDS.Path.CommandsStore=!SDS.Path.PackagesStore!\Commands

; Path to the groups directory
SDS.Path.GroupStore=!SDS.Path.PackagesStore!\Groups

; Path to the bin directory
SDS.Path.BinStore=!SDS.Path.ExecutionPath!\Internal

; Path, where packages will be stored on local computer
SDS.Path.LocalStore=c:\Program Files\SDS

; Path to the regular jobs directory
SDS.Path.JobStore=!SDS.Path.ExecutionPath!\Jobs\Regular

; Path to the internal jobs directory
SDS.Path.InternalJobStore=!SDS.Path.ExecutionPath!\Jobs\Internal

; Path to the temporary (per session) files
SDS.Path.Temporary=!SDS.Path.ExecutionPath!\Temporary

; Path to the frontend folders, which allows you to securely allow users to install software on their own PC (similar to published feature)
SDS.Path.FrontendFolders=\\!ComputerName!\SDS

Please let me know what you dont understand... I am not good at writing easy-to-understand documentation

Martin

[Martin Zugec]

This is example. On this picture you can see active job AdobeReader (JobState Running). This job is associated with computers on right (pc####).

Green ones were successful, red failed (in fact I forced that computer to fail), blue means the installation is running right now.

The last three computers were not activated yet, because they are turned off. When user turns them on, Adobe Reader will be automatically installed.

BTW this is alpha GUI, I am not GUI programmer, so excuse the layout

Martin

Attached File(s)

•  SDS.GIF (32.4K)
  Number of downloads: 76

[Martin Zugec]

Dman agreed to create Package generator GUI! Welcome to team man

[Martin Zugec]

I will now talk about Default packages.

You can see them in Main.ini... What are they?

Default packages are in my opinion really nice idea, that make SDS open to further modifications... We can say they are acting like plugins...

There are two different default package types - Start and End. The default packages are "around" every job - for example if you run job AdobeReader, all SDS.Global.DefaultPackages.Start.# will be performed BEFORE AdobeReader and all SDS.Global.DefaultPackages.End.# will be performed AFTER AdobeReader.

As I said it is quite useful for plugin functions - for example I am using
SDS.Global.DefaultPackages.Start.3=Command:Disable_Input
and
SDS.Global.DefaultPackages.End.3=Command:Enable_Input

This will perform command Disable_Input before installation and enable input after installation.

This example will block user input (mouse+keyboard) for duration of installation.

In fact DefaultPackages are really easy to implement/understand...

Any questions?

[Martin Zugec]

I am looking for someone that is able to create utility to schedule one task + share folders...

Anyone?

[gunsmokingman]

Hey Martin go to this web page it explains all the varibles for this script
Hey Script Guys

Quote

Const FILE_SHARE = 0
Const MAXIMUM_CONNECTIONS = 25

strComputer = "atl-ws-01"
Set objWMIService = GetObject _
    ("winmgmts:\\" & strComputer & "\root\cimv2")

Set objNewShare = objWMIService.Get("Win32_Share")

errReturn = objNewShare.Create _
    ("C:\Public", "PublicShare", FILE_SHARE, _
        MAXIMUM_CONNECTIONS, "Public share for Fabrikam employees.")

Go to this web page for the varibles and stuff for this script.
Hey Script Guys

Quote

strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set objNewJob = objWMIService.Get("Win32_ScheduledJob")
errJobCreated = objNewJob.Create _
    ("Cleanup.exe", "********123000.000000-420", _
        True , 1 OR 4 OR 16, , , JobID)
Wscript.Echo errJobCreated

[Martin Zugec]

Hi GSM!

I was all the time thinking about APIs and .net classes, that I forget about wmi classes!

Thanks, I will work on it (or you can, if you would like to help)...

[gunsmokingman]

Send me the info needed and I will try and do it.
Gsm

[Martin Zugec]

Sent to your mail... Hope so we will see it from you ASAP

Martin

[Martin Zugec]

FYI: I changed blog to http://msmvps.com/martinzugec

[Martin Zugec]

So guys (Dman and GSM), how are you doin?

I presented SDS yesterday on one presentation and administrators were VERY interested in it

[Martin Zugec]

Maybe someone might help me...

I need to import configuration files for batches to GUI... Inside these files are variables, dont any of you have function for parsing these variables?

I am working in VB.NET, however code written in C# will be fine for me.

[gunsmokingman]

The Task schedule seems very hard to do.
You have to create the task then delete the task to recreate the task
to do what you want. This is my understanding on what I have read about it.

Martin would it not be better to start the script as soon as some one logs on.
Then you could leave it in a loop that does not end.
This loop would keep going because there is no -1

Quote

Dim Inta : Inta = 1-1
Do
Inta = Inta + 1
'''' Your Action Here
wscript.sleep 60000
Loop Until Inta = -1

The share folder I have no way of testing that.

[dman]

Hi Martin,
I have been so busy I don't have time to pee. Hope to dig into this over the weekend :-)

[Martin Zugec]

2Dman: No prob, this is hobby project

2GSM: Nope, that is not good The problem is any error during script will block whole execution, whether batch services are independent on each other + you can create threaded execution...
If it is really big problem, I could write it in .NET...

[gunsmokingman]

It is kinda of a problem in vbs because as I understand it you must
create the task then delete the task. You would have to do this for
each task.
The loop you could add I believe a way to handle errors

Quote

On Error Resume Next

Here is a example of what I mean

Quote

Dim Act, Fso, SD, Test
Set Fso = CreateObject("Scripting.FileSystemObject")
Set Act = CreateObject("Wscript.shell")
SD = Act.ExpandEnvironmentStrings("%systemdrive%")
Test = Array("\Test5","\Test4","\Test3","\Test2")

For Each StrTest In Test
Fso.CreateFolder(SD & StrTest)
Next
Act.Run(SD)
MsgBox "Part One Of The Test Completed"
On Error Resume Next
Fso.DeleteFolder(SD &"\Test1")
Fso.DeleteFolder(SD &"\Test2")
Fso.DeleteFolder(SD &"\Test3")
Fso.DeleteFolder(SD &"\Test4")
Fso.DeleteFolder(SD &"\Test5")

Here Is Another Example

Quote

Dim Act, Fso, SD, RunTest
Set Fso = CreateObject("Scripting.FileSystemObject")
Set Act = CreateObject("Wscript.Shell")
SD = Act.ExpandEnvironmentStrings("%systemdrive%")
RunTest = Array(_
SD & "\Windows\Notepad.exe",SD & "\Windows\SmokePad.exe",_
SD & "\Windows\System32\Mspaint.exe",SD & "\Windows\System32\Martin.exe")
For Each StrRunTest In RunTest
If Fso.FileExists(StrRunTest) Then
Act.Run(StrRunTest),1,True
Act.Popup "Completed The Test" & vbCrLf & strRunTest, 5, "Completed", 0 + 32
Else
Act.Popup "Error In The Test" & vbCrLf & strRunTest, 5, "Error", 0 + 32
End If
Next

[Martin Zugec]

Hmmm, I can see the problem

The Win32_ScheduledJob class doesnt support that kind of job I would like to see

Looks like we will need to find some workaround...

Dman, what do you think, could you create it using C++? I would like to use as less as possible of .NET, because it require runtime