Shawn
|
| (KiX Supporter) |
| 2007-12-02 04:05 PM |
|
Installing packages via GPO Startup script.
|
Moved discussion of this to here.
So Witto, your function here uses this syntax in your INI file:
;NetworkID
; Network or networks where computer should be to allow software installation
; The format of the list of networks should be build like this
; xxx.xxx.xxx.xxx/yy;xxx.xxx.xxx.xxx/yy;xxx.xxx.xxx.xxx/yy
; where xxx.xxx.xxx.xxx is the NetworkID and yy is the Net Mask
; preceeding zero's should not be used
; In example:
; NetworkID=192.168.1.0/24;172.16.0.0/27
I'm not a network weenie - can you explain how this mask works ... does that mean apply the package to machines with the IP 192.168.1.0 to .24 or is that "24" more of a binary mask ?
[edit]
So if I wanted all ip with 192.168.1.* one would use 255 as that second number ?
-Shawn
| Gargoyle |
| (MM club member) |
| 2007-12-02 04:25 PM |
|
|
Re: Installing packages via GPO Startup script.
|
If Witto is using it in the standardized notation form, it would be the binary mask I.E. yy = the number of bits that are masked - 24 would be the same as saying 255.255.255.0 - 27 would be 255.255.255.224 etc.
| Witto |
| (MM club member) |
| 2007-12-02 04:41 PM |
|
|
Re: Installing packages via GPO Startup script.
|
The net mask can be written in decimal numbers or in binary numbers.
If you write it binary, you just tell how much 1's you see.
Try to make it clear like this:
Code:
/20 = 11111111.11111111.11110000.00000000 = 255.255.240.0 /21 = 11111111.11111111.11111000.00000000 = 255.255.248.0 /22 = 11111111.11111111.11111100.00000000 = 255.255.252.0 /23 = 11111111.11111111.11111110.00000000 = 255.255.254.0 /24 = 11111111.11111111.11111111.00000000 = 255.255.255.0 /25 = 11111111.11111111.11111111.10000000 = 255.255.255.128 /26 = 11111111.11111111.11111111.11000000 = 255.255.255.192 /27 = 11111111.11111111.11111111.11100000 = 255.255.255.224 /28 = 11111111.11111111.11111111.11110000 = 255.255.255.240 /29 = 11111111.11111111.11111111.11111000 = 255.255.255.248 /30 = 11111111.11111111.11111111.11111100 = 255.255.255.252 /31 = 11111111.11111111.11111111.11111110 = 255.255.255.254 /32 = 11111111.11111111.11111111.11111111 = 255.255.255.255
172.16.0.0/27 means:
a subnet of the class B network 172.16.0.0
(default network mask = 255.255.0.0 or /16)
network address = 172.16.0.0
host adresses: 172.16.0.1 - 172.16.0.30
broadcast adress = 172.16.0.31
Here it is explained by someone else:
http://www.nongnu.org/lpi-manuals/lpi-102/html/ch05s02.html
[Edit]
Thanks Gargoyle, you hit the nail right on the head
[/Edit]
[Edit]
192.168.1.* would be 192.168.1.0/24
[/Edit]
|
Shawn
|
| (KiX Supporter) |
| 2007-12-02 05:24 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
So if you wanted to hit just a single machine, you would say:
192.168.1.36/32
?
| Arend_ |
| (MM club member) |
| 2007-12-02 05:33 PM |
|
|
Re: Installing packages via GPO Startup script.
|
Why not stick the GPO to the OU the computer is in and be done with it, no scripting neccesary
| Witto |
| (MM club member) |
| 2007-12-02 08:32 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
Originally Posted By: Shawn
So if you wanted to hit just a single machine
The net mask is to define the network where the software installation is allowed. If I am at home, working via VPN, I would not want that the software package starts installing. Just a matter of bandwith.
If you only have the network 192.168.1.0/24 at work, you would want that your computer has an address in that network before installing the software. But are you sure that the computer you want to install the software to always has address 192.168.1.36? Don't you use DHCP?
NetworkID in the INI-file refers to "Network Addresses" and the masks of the networks where you want to allow the installation.
Originally Posted By: apronk
Why not stick the GPO to the OU the computer is in and be done with it
| Arend_ |
| (MM club member) |
| 2007-12-02 08:51 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
Originally Posted By: Witto
Originally Posted By: apronk
Why not stick the GPO to the OU the computer is in and be done with it
Then create a Computer Group for instance named "appl_package".
Then make a GPO with the same name and have the package deployed there.
Link the GPO to the computer group in the security tab. And you're done. simply add computers that need that package to that computer group.
| Witto |
| (MM club member) |
| 2007-12-02 09:04 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
Wasn't it that what I was explaining?
| Arend_ |
| (MM club member) |
| 2007-12-02 09:07 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
Originally Posted By: Witto
Wasn't it that what I was explaining?
Ehm, yeah... sorry I didn't really read it
|
Shawn
|
| (KiX Supporter) |
| 2007-12-02 09:38 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
We will be deploying this script to ALL workstations in the OU (1000's of machines) - just looking for a way to perform the following:
1) Impact only a handful of machines in the short-term (our soak).
2) Possibly increase this to more than a handful if required (extended soak).
3) Release to everyone.
Plus - this script would not be specific to just installing a single package. Will probably enhance to install many packages over the years.
| Witto |
| (MM club member) |
| 2007-12-02 09:47 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
We just have about 150 workstations (for administrative purposes). I cannot say what impact the script will have in your situation. I just was looking for a way to install non MSI packages that do support silent installations.
|
Shawn
|
| (KiX Supporter) |
| 2007-12-02 09:55 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
I have a gut-feeling this concept will work. Every workstation will run the script, and logic would be something like:
Code:
if (this workstation is in scope for package A) install package A enndif if (this workstation is in scope for package B) install package B endif etc, etc
Its the determination of "in-scope" I need to work-out. Unfortunately that could be just about anything ... from a simple list of hostnames to some other more complex criteria (like using the IP address). Will probably just custom code these IF statements as opposed to "softening them up" in an INI file like you did (your way is more eloquent imho).
| Witto |
| (MM club member) |
| 2007-12-02 10:06 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
If I understand what you mean, that is also in the script.
The INI file contains a section per package. Create a GPO per section. In the Startup Script parameters, you refer to the section:
Code:
\\domain-name\SysVol\domain-name\scripts\script.kix $INI="\\domain-name\SysVol\domain-name\scripts\script.ini" $Section="Package Name"
|
NTDOC
|
| (KiX Master) |
| 2007-12-03 12:57 AM |
|
|
Re: Installing packages via GPO Startup script.
|
You guys rolling out SAP again there Shawn?
|
Shawn
|
| (KiX Supporter) |
| 2007-12-03 01:07 AM |
|
|
|
Re: Installing packages via GPO Startup script.
|
Lol. Nah - we're putting out UPHClean. Having big problems with locked registry on logoff - especially on our VMWARE sessions.
-Shawn
| Les |
| (KiX Master) |
| 2007-12-03 01:15 AM |
|
Re: Installing packages via GPO Startup script.
|
It is a nice utility. I install it on all my Citrix servers. Lemme guess... Symantec locking your reg?
|
Shawn
|
| (KiX Supporter) |
| 2007-12-03 02:04 AM |
|
|
|
Re: Installing packages via GPO Startup script.
|
Hehee nah, we dont use Symantec - but we do have some in-house applications that are hanging on to the registry. Tell you another bit of software that seems to run crap on VMWARE - McAfee Host Intrusion Protection (HIP) and Site Advisor ... we have people looking into this issue but damn - they had to remove it from all our virtual sessions - something about locking them up too.
|
NTDOC
|
| (KiX Master) |
| 2007-12-03 05:23 AM |
|
|
|
Re: Installing packages via GPO Startup script.
|
Oh... we don't need to push it out as it's in all our Ghost images
Been using it for years in our images, since my Disney days.
Though I'm about 99% certain that some recent "Critical Update" from MS is causing a yellow exclamation in the Event Viewer about the registry hive of the current user not be released properly. Never used to see it till recently and MS updates are the only things that get added to most of these systems and users are not Admins.
Have not really researched much more as it still unloads quickly due to UPH but PITA that MS changed something that is now causing it to happen on systems that had clean logs for months.
| Witto |
| (MM club member) |
| 2007-12-03 10:24 AM |
|
|
|
Re: Installing packages via GPO Startup script.
|
Shawn,
Forgot to tell that (installations via) computer startup scripts don't make the user wait to log on. I use it for small installations. I presume when you roll out big installations that take several minutes to install, users will be able to log on to their computers while installation is still ongoing. I don't know if that is an issue. Maybe, if needed, you can script something that asks the user to wait untill the installation has ended. I know you are great with kixforms.
|
Jochen
|
| (KiX Supporter) |
| 2007-12-03 10:30 AM |
|
|
Re: Installing packages via GPO Startup script.
|
Originally Posted By: Witto
I know you are great with kixforms.
Umm, well, if not Shawn, who else?
|
NTDOC
|
| (KiX Master) |
| 2007-12-03 10:50 AM |
|
|
|
Re: Installing packages via GPO Startup script.
|
Maybe Benny can help him out
|
Shawn
|
| (KiX Supporter) |
| 2007-12-03 01:37 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
I'm not too worried about user's logging in while the script is running. In fact, all of our workstations perform an automatic reboot at 2am morning. So I would assume thats when this script would run.
Having said that, going to get our GPO guy to set this up in our test domain this morning. So what settings do I give him:
Startup Script: c:\windows\system32\wkix32.exe
Parameters: startup.kix
Will it know to find startup.kix on NETLOGON or does one have to be more specific ?
|
Jochen
|
| (KiX Supporter) |
| 2007-12-03 01:46 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
If startup.kix resides in "c:\windows\system32\" you don't have to worry me thinx
manual quote :
Quote:
Locating Files
During the logon sequence, KiXtart automatically tries to locate all files that it is asked to open (SPK, WAV, TXT, and so on) by searching for them first on the NETLOGON drive, then on the drive where KiXtart was started from, and finally in the current directory. This behavior can be overridden by prepending the filename with a drive letter or a UNC path.
During the logon sequence, KiXtart automatically tries to locate all files that it is asked to open (SPK, WAV, TXT, and so on) by searching for them first on the NETLOGON drive, then on the drive where KiXtart was started from, and finally in the current directory. This behavior can be overridden by prepending the filename with a drive letter or a UNC path.
This is not exactly a logon sequence, it's more a startup sequence...
I can't tell if locating files works likewise in startup scripts.
hth
|
Shawn
|
| (KiX Supporter) |
| 2007-12-03 02:45 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
Well, you would think that "NETLOGON" would mean nothing to a startup script - its not like a user is logging on. But there must be some way of determining which DC the script came from.
|
Jochen
|
| (KiX Supporter) |
| 2007-12-03 03:46 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
If you create the domain policy object in an AD Domain, it will result in a path creation like this : \\domain.name\sysvol\domain.name.again\policies\{Object-GUID}\Machine\Scripts\Startup\
what if you place wkix32 and the script there?
(this is only an assumption from given structures in our domain, sorry, I am not responsible for Policies here
)
|
Shawn
|
| (KiX Supporter) |
| 2007-12-03 04:26 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
hehee, thats exactly what we just tried Cappy. We specified this in the policy:
ScriptName: wkix32.exe
Parameter: startup.kix
You were right about the "windows will find wkix32.exe in system32". Then we put startup.kix in that sysvol\..\{GUID}\.. path - and it works a charm. Right on man.
Now - just about to change this startup.kix script to "dump" all the environment settings to a local file - to see what kind of context we can utilize.
-Shawn
|
Shawn
|
| (KiX Supporter) |
| 2007-12-03 05:01 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
Ahhh ok - Interesting...
Windows added the "sysvol\..\{GUID}\.." thingy path to the BEGINNING of your PATH environment variable !
The other interesting setting is this:
USERPROFILE=D:\Documents and Settings\Default User
Having said that - a lot of settings are missing, like USERDOMAIN and USERNAME, HOMEDRIVE, HOMEPATH etc ... not totally un-expected I guess. We are running in the system context.
| Arend_ |
| (MM club member) |
| 2007-12-03 06:38 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
One could also use Zap files to deploy, or use the zap file to call a kix file without having to go trough the sysvol guid stuff. Just to add my contribution to this convo
| Witto |
| (MM club member) |
| 2007-12-03 08:22 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
True, but IMHO the biggest issue with zap files is documented in the article kb231747 you refer to:
Quote:
Non-MSI program can be published only to users, and are installed using their existing Setup programs. Because non-MSI programs use their existing Setup programs, these programs cannot:
• Take advantage of elevated privileges for installation.
ZAP files install with the user privileges. In most cases, you would have to make the user a local admin.
It also is only to be used at user level of the GPO, not computer level.
About where to find the kix executable (kix32.exe or wkix32.exe)
I only maintain one copy of the file in \\domain\netlogon (same as \\domain.ext\sysvol\domain.ext\scripts)
The paths I give are:
Script Name
\\domain.ext\sysvol\domain.ext\scripts\wkix32.exe
Script Parameters
\\domain.ext\sysvol\domain.ext\scripts\script.kix $INI="\\domain.ext\sysvol\domain.ext\scripts\script.ini" $Section="Package Name"
IMHO this makes the script and the executable much easier to maintain and you can use it over and over again for other policies. Just ad sections to the INI file per installation. Create a group policy per installation.
|
NTDOC
|
| (KiX Master) |
| 2007-12-03 09:25 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
Okay Shawn, don't be shy. Bust out your RunNas file and be done with it. LOL
|
Shawn
|
| (KiX Supporter) |
| 2007-12-03 09:58 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
We use runnas in-house (although I renamed the executable to something more ... inconspicuous yeah). But hey - with these startup scripts - no more need for that. So far our testing on this startup stuff has been very positive.
|
NTDOC
|
| (KiX Master) |
| 2007-12-03 10:25 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
Yes it does work well. However I think if you do a physical audit of event viewers on local PC I think you will find a small number that are not using the policy for one reason or another often due to minor issues on the system.
We did an audit at Disney once and found that we had around 100 computers out of a few thousand that were not properly processing policies for one reason or another and they had to be updated/repaired to fix.
|
Shawn
|
| (KiX Supporter) |
| 2007-12-03 10:50 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
[Shawn places his hands over his ears]
I can't hear you ... I can't hear you !
;-)
-Shawn
|
NTDOC
|
| (KiX Master) |
| 2007-12-04 07:55 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
Well then if you're not using DFS or DFSR then you're looking to shoot yourself in the foot sooner or later using GPO installs.
I have not used or messed with GPO software installs for many years but I knew there was something I didn't like about them and this is why.
IT Pro Magazine has an article on it but since you probably don't subscribe here is a similar link for it.
http://www.activedir.org/article.aspx?aid=105
http://www.windowsdevcenter.com/pub/a/windows/2005/04/05/dfs.html
| Witto |
| (MM club member) |
| 2007-12-04 08:28 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
That is about GPO Installations.
If you install office 2003 that way, you do not get a C:\MSOCACHE folder.
What I am telling is to use a GPO Computer Startup Script. I am sure that if you would install office 2003 in that way, you do get a C:\MSOCACHE folder (but I would not start deploying Office 2003 via Startup Script).
|
NTDOC
|
| (KiX Master) |
| 2007-12-04 08:52 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
Can or does a Startup Script understand using a SCRIPTS GUID folder from any DC ?
I know you can point it to one specific one but have not tried to do one with using GUID
| Les |
| (KiX Master) |
| 2007-12-04 10:48 PM |
|
Re: Installing packages via GPO Startup script.
|
I would never reference the GUID folder directly but rather host what I need in Netlogon. I don't even put the KiX script in the GUID folder, just a BATch file.
|
NTDOC
|
| (KiX Master) |
| 2007-12-04 11:08 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
Thanks Les.
I suppose I should mess around with this stuff again to confirm how it really does work. Been many years now since I've played with it.
|
Shawn
|
| (KiX Supporter) |
| 2007-12-04 11:43 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
Quote:
Can or does a Startup Script understand using a SCRIPTS GUID folder from any DC ?
We're facing this "issue" right now. I am currently using @SCRIPTDIR to determine (in a soft way) which GUID folder I am running from.
Throwing another question out there - has anybody installed UHPCLean via startup script ? Telling you right now - its not working too well. Its only half-installing - damn ugly.
-Shawn
|
NTDOC
|
| (KiX Master) |
| 2007-12-04 11:56 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
Anything in the event viewer to say what is failing ?
[NTDOC places his hands over his ears]
I can't hear you ... I can't hear you !
| Witto |
| (MM club member) |
| 2007-12-04 11:57 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
UPHClean is an msi installer. Why not use a "Software installation" via the "Software Settings" under "Computer Configuration"?
|
NTDOC
|
| (KiX Master) |
| 2007-12-05 12:03 AM |
|
|
|
Re: Installing packages via GPO Startup script.
|
Well curious what real difference that would make. If both methods have local admin rights then why would a startup script fail?
|
Shawn
|
| (KiX Supporter) |
| 2007-12-05 12:04 AM |
|
|
|
Re: Installing packages via GPO Startup script.
|
We vowed never ever to use GPO software installation again. Had many issues in the past with inconsistent results and no nice way to determine which machines actually got the software. I remember the guy responsible telling me that sometimes it would take multiple reboots before the installation stuck.
I dont know. You think an msi installation with startup script not a good idea ?
|
NTDOC
|
| (KiX Master) |
| 2007-12-05 12:07 AM |
|
|
|
Re: Installing packages via GPO Startup script.
|
[I can't hear you]
But when I could I thought I heard you say you were going to just do it.
So Event Viewer says nothing? Then maybe you need to enable auditing on them boxes.
|
Shawn
|
| (KiX Supporter) |
| 2007-12-05 12:09 AM |
|
|
|
Re: Installing packages via GPO Startup script.
|
I am currently on a conference call with "the team". We just made the decision to stick with the startup script - but get rid of the MSI ... we're going to use the "manual install of UPHClean" approach - described in the UPHClean readme. Just want to get MSI out of the equation.
-Shawn
|
Shawn
|
| (KiX Supporter) |
| 2007-12-05 12:15 AM |
|
|
|
Re: Installing packages via GPO Startup script.
|
Doc to answer your question. The UPHClean msi engine returns a good result (zero) but it doesn't add an entry into add/removes. If one installs it as a user manually (thru the wizard) - an entry is created in add/removes.
If one tries to un-install this "mostly installed version", the msi complains that its not installed (i assume because its not in add/remove).
In terms of the eventlog no - nothing there. We do have the msi log though and reviewing.
| Witto |
| (MM club member) |
| 2007-12-05 12:46 AM |
|
|
|
Re: Installing packages via GPO Startup script.
|
I would think both "startup script" and "software installation" can be used to install software.
Via the startup script, I had to find some checks to avoid installing software over and over again, like looking for the uninstall key in the registry.
Microsoft also has it's ways to determine if software has been installed. There are things (advantages?) like the possibility to redeploy a package, or the possibility for the user to repair the software.
http://support.microsoft.com/kb/816102
http://technet.microsoft.com/en-us/library/bb742421.aspx
A few years ago, we deployed Office 2003 with some MUI via GPO, Software Installation under Computer Configuration. I think the only issue we had was lack of space on some computers (6 GB Hard Drives...).
About eight moths ago, we deployed new computers with Office 2003 in the image I created.
|
Shawn
|
| (KiX Supporter) |
| 2007-12-05 12:50 AM |
|
|
|
Re: Installing packages via GPO Startup script.
|
Did you use the "install when the user clicks it" method or the "just install it" approach ? Forget the terminology - think the tech term is "assign the package" versus "not assign it".
| Witto |
| (MM club member) |
| 2007-12-05 12:51 AM |
|
|
|
Re: Installing packages via GPO Startup script.
|
It was in the computer portion of the GPO, installed at reboot.
|
Shawn
|
| (KiX Supporter) |
| 2007-12-06 07:05 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
We've had to shelve the UPHClean - we're getting too many BSODS when un-installing UPHClean ... about 1 out of 7 machines. A lot of people have asked me "why are you even un-installing it - just slap it in and be done with it". Our platform has much rigor and process and quality assurance - we have to demonstrate that the software can be reliably installed and easily removed on demand. I'm sure your platforms are the same way. Might be in this case that our "process" has caught a potential day-two issue early - idk.
Has anyone out there experienced Blue Screens with un-installing UPHClean ?
btw - the UPHClean readme talks about potential blue screens.
|
Shawn
|
| (KiX Supporter) |
| 2007-12-06 07:08 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
Oh - and most important - GPO Startup scripts work a charm. It was unfortunate that the first thing we tried to install (UPHClean) cast a shadow on this wonderfull feature of AD. It truely is sweet. Can't wait to find a new use for this goody.
|
NTDOC
|
| (KiX Master) |
| 2007-12-06 07:38 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
Originally Posted By: Shawn
Can't wait to find a new use for this goody.
KiXforms ?
| Witto |
| (MM club member) |
| 2007-12-07 10:49 AM |
|
|
|
Re: Installing packages via GPO Startup script.
|
Kixforms is an msi package. It can also be done via "Software Installation". But if you don't like the GPO Software installation, it is a possibility.
| Mart |
| (KiX Supporter) |
| 2007-12-07 11:34 AM |
|
|
Re: Installing packages via GPO Startup script.
|
Deploying kixforms classic with as GPO worked fine for me for several years.
A few months ago we switched to kixforms.net and got a whole lot of cr#p. Deploying KF.net with a startup script does not work as great as it does with KF classic. Using a GPO to deploy the MSI package worked fine so we switched from a startup script to a GPO.
|
Shawn
|
| (KiX Supporter) |
| 2007-12-07 02:44 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
Mart. You switched from Startup Script to GPO push do deploy Kixforms.Net ? Have any theories why it would work under GPO and not Startup ? Maybe something to do with "the context" they run under ? We were working on that theory for our issue.
| Mart |
| (KiX Supporter) |
| 2007-12-07 04:21 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
It has to do with the fact that the .net flavor won't register with regsvr32. It does with regasm but that basta won't run correct in my startup script.
Using a GPO now to deploy the .net MSI and it works great on all systems. Users are happy, CEO is happy, I get paid so I'm happy to
This way it is also easier to manage imho. If there is a new version of kf.net that we are going to use in production then scrap or unlink the old GPO, create a new one and all is done.
|
Shawn
|
| (KiX Supporter) |
| 2007-12-07 04:43 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
Yeah, with regsvr32 its easy to understand whats it doing under the covers - just making a bunch of HKCR additions and linking them together by CLSID. Regasm is another thing altogether - it registers crap just like regsvr32 - but it also does some kind of magic in dotnet. Registering with "the global catalog" etc etc iirc. Don't pretend to understand even at a high level whats going on under the covers.
| Mart |
| (KiX Supporter) |
| 2007-12-07 09:55 PM |
|
|
|
Re: Installing packages via GPO Startup script.
|
Quote:
....
Don't pretend to understand even at a high level what's going on under the covers.
There is stuff one does not want to know. This might be one of these things. We have it working great now and are happy with this solution for now.