ajbritton

I had forgotten to mention that my MSI also adds the following INI file entries; %WINDIR%\CONNECT.INI [sIMSConnection] ServerName=MySIMSServerName\SIMS DatabaseName=SIMS %INSTALLDIR%\CONNECT.INI [sIMSConnection] Redirect=S:\SIMS [sIMSOffline] PreviousRedirect=S:\SIMS PreviousServerName=MySIMSServer\SIMS PreviousDatabaseName=SIMS PreviousDatabaseMode=OnLine %WINDIR%\SIMS.INI [setup] SIMSSetupsDirectory=S:\SIMS\Setups

A thought occurs. If you are using ADMT, then it will move your computer accounts from the source domain to the target domain. There is no particular need in that respect to keep your existing domain name. I assume you are aware the every PC will need to have an 'agent' loaded and be switched on when you do the migration...

It is possible to have two domains with the same name and even servers with the same name of the network at the same time. It's even possible to access one from the other by using the IP address rather than the name. The log files will show errors, and workstations may not log on correctly, but that should not matter if you are doing a migration. Having said all that, I doubt that ADMT will migrate from one domain to another with the same name. I'm NOT an ADMT expert however. It might be worth looking at the latest version of ADMT (here) which is 3.

@Mark: What happens if you run these commands interactively one at a time? Come to that, how did you sequence them together in the first place? I assume as a .BAT/.CMD file. I will test.

You'll probably find that your OU structure will change as your network evolves and you better understand what it needs to do and how you need to manage it. For what it's worth, here's my complete standard structure. \Managed \Computers \ICT Suite \Classrooms \Library \School Laptops (these seldom leave the school) \Staff Laptops (these go home with staff and connect to Internet) \Groups \Servers \Service Accounts \Users \Managers \Staff \Students

Logon script? That would slow things down a bit for the poor users.

The Wake-On-LAN function relies on MS DHCP server, and it only works with PCs that have acquired an address which is not a reservation. Not a major problem, and they are working on it.

R U sure you waited long enough? When I do this via an MSI and GP, the install takes yonks. Have you tried watching the process list for cpu activity?

Reinstall then backup!

What policies did you set?

Thanks guys. I'm fairly sure it was the script packager in Admin Script Editor that I was thinking of. Now the question is, do I shell out the cash?

Well for what it's worth I'll be popping a lot of stuff up soon regarding primary school software (2simple, etc.. ) shortly as I'm about to tackle installing by GPO instead of using ghosted complete images... Expect ranting :? You may already know this, but 2Simple will happily supply MSI files for all their software. Having said that, some of them are less than perfect!

I want to create a startup script which can start a process with network access. I seem to remember that there is a script tool which will let you do this, but I can't remember what it's called. In essence, I will need to create a special domain user account with a strong password and encode these into the script which would have to be encoded to prevent the password being extracted. I don't think this is possible in AutoIT. Any ideas?

Oops - which container/ou did you link your policy to? It sounds like you linked it to the root of the tree. Policies are inherited down the tree (unless you specifically block inheritance). Best pratcise is to create Organizational Units (like containers) to put your computers/users in. I use a structure as a bit like this... \Managed \Managed\Computers - (computer accounts are all in here) \Managed\Users \Managed\Users\Staff - (staff user accounts are all in here) \Managed\Users\Students- (student user accounts are all in here) When you want a policy to apply to all your users, you can create it at the \Managed\Users level. Policies for staff or students would created at the appropriate level to just apply to those users. You should also create OUs for other objects (eg Groups, Service Accounts, Admin Accounts). You should also avoid editing the default policies (default domain policy, default domain controller policy, default site policy).

As others have said, it won't be possible to host repackaged MSIs for licensed software. Best bet might be as follows... For each application/version... 1 - Details of the native installer (is it InstallShield, Nullsoft, Wise, MSI etc.) 2 - How to do a silent install. (ISS files, command line switches etc.) 3 - How to pre/post configure the installation. (This would include creating MST files, which could be hosted, for MSI based installers) 4 - Any tips on repackaging the particular app (eg. Don't forget to exclude Flash files, Don't need to include HKCU entries) There is obviously a good deal of duplication of the good work that goes on at AppDeploy and a few other places. I suppose if a particular package is well covered elsewhere then it could be linked to.

NOOOOOOoooooooooo!!!! WHHHHHHHhhhhhhhhyyyyyyyy?????

Go get this now and be able to startup/shutdown remote PCs and force gpupdates.

Nope, I run them exactly as I specified them. The S: drive does not exist at install time but that doesn't seem to matter. I share the SIMS\Setups directory as SIMSSETUPS and make sure Authenticated Users have Read access. I generally add the Staff or SIMSUSERS group to the local Power Users group and that should take care of permissions issues.

You might also SIMS Resource 5967 (Technical Guide - Command Line Use of SIMS Installers) interesting.

You need to do the following... (Path to SIMS Setups)\SIMSInfrastructureSetup.exe -a {QuietMode} (Path to SIMS Setups)\SIMSApplicationSetup.exe /S {QuietMode} {NoServerApps} [sIMSDirectory]="S:\SIMS" [sIMSDotNetDirectory]="C:\Program Files\SIMS\SIMS .net" (Path to SIMS Setups)\SIMSMAnualSetup.exe /S {QuietMode} {NoServerManuals} [sIMSDirectory]="S:\SIMS" [sIMSDotNetDirectory]="C:\Program Files\SIMS\SIMS .net" Obviously, permissions on SIMS Setups must be correct.

@Norphy - I think you misunderstand me. I want to roll out the Smartboard software with a targeted GPO. The WMI filter should include only machines with the smartboard (which I believe is detected by Windows but appears as 'unknown device' in device manager). So far it looks like I need to use the Win32_PnPEntity.DeviceID property, which has the vendor and device information in it.

I want to create a WMI filter to target the SMARTboard software installation. I've yet to create my first WMI filter and was wondering if anyone has already done this, or something similar? Come to think of it, some sample WMI filters on the WiKi might be good...

If all this GP twiddling fails, here's another way you could do it... 1 - Redirect all Start Menus to C:\StartMenu (or anything on the local PC) - Do this for ALL USERS. 2 - Apply a startup script to the desktop machines OU which copies the managed start menu from the network down to C:\StartMenu. (This can be done if you include the files being copied in the actual GPO alongside the script) 3 - Apply a startup script to the laptops OU which simply copies the contents of the original start menu (%ALLUSERSPROFILE%\Start Menu) to C:\StartMenu This way you still take control of the Start Menu contents. Too whacky?

Don't know for sure but it's probably a registry thing. You could try using RegShot to compare the registry before and after you make the changes manually. Kellys Korner is a good place for XP tweaks. Assuming it is registry based, then capture the settings in a .REG file and merge at logon.

Assuming xall your clients are win2k/xp then you don't need to set the dns domain name as this is set when they join the domain.