ajbritton

I'm looking for an online/self study MCSE course that would be a lot less expensive that going to a training center. Does anyone know of such a thing? Any reccomendations? Thanks,,,

Surely once the PC has been built, renamed and moved to the right OU then reimaging is just as painless. As for the self healing, surely thats a function of Windows going back to the installation source which would be the same regardless of prestaging. The only reason I can think of to pre-stage is in corporate environments where installation engineers do not have permissions to create computer accounts. The computer account must be pre-created by the infrastructure people (or whatever) and then the PFY gets the PC out of the box, plugs it in and kicks off the RIS build. I suppose the other reason might be to load balance across several RIS servers on different subnets.. FWIW here's what I do when installing a batch of new PCs 1 - Configure RIS server to name PCs NP+MAC and put all new accounts in a temporary OU which will pick up basic software used school wide. 2 - Build each PC, noting its location and last 5 digits of MAC (this is displayed during the client installation wizard) 3 - Once all the PCs are starting to build, go to the server and move all the computer accounts to their required destination. 4 - Rename the computers remotely using either MSTSC or VNC. ...and another thing; surely prestaging requires the UUID, not the MAC address. A bit tedious to boot every new PC, run a utility to get the UUID, write it down (majorly prone to error). Unless of course the supplier gives you a list of UUID to serial numbers.

You cannot use MSTSC to remote control a limited user for the following reason; When you use /console to log into the remote machine, you must log on as the same user that is logged on at the remote machine. By default, limited users cannot do this (for good reason!) AFAIK the /console switch works with 2003 server and XP only. In fact, with XP it is implicit. It's not possible to connect to any session other than the console. UltraVNC is the way to go.

Camilla Queen

@Geoff: Interesting. I notice that both Scalix and Zimbra support Outlook calendar sharing, but not in the free versions. I don't suppose you know of an email service that is free AND supports Outlook calendar??

@Michael - Surely that would set the password policies for user accounts on the computers, not the domain.

You could cobble together an AutoIT script which watches for the presence of high risk applications being open and shortens the ScreenSaverTimeOut registry value, or spots whiteboard apps and disables screensaver. The script could be set to loop forever but sleep for 5 seconds between checks. Opt("WinTitleMatchMode", 2) ;1=start, 2=subStr, 3=exact, 4=advanced Do $MaxTimeout = 15 * 60 ;15 minutes if WinExists("SIMS") then $MaxTimeout = 1 * 60 ;1 minute ElseIf WinExists("WhiteboardApp") then $MaxTimeout = 30 * 60 ;30 minutes EndIf RegWrite("HKEY_CURRENT_USER\Control Panel\Desktop", "ScreenSaveTimeOut", "REG_SZ", $MaxTimeout) Sleep(5000) Until 1 = 0 NB - This script has not been tested !!

No such thing as a free lunch. My bet is you will still have to go through some process akin to repackaging to get the package into a form suitable for deployment via SVS. You may as well just repackage and deploy with GP.

The link that apeo posted is your starting point. That will tell you which commands you need to run. You then need something like Windows Installer Wrapper Wizard (see the Essential Software pages on the WIKI). You can then cobble together an MSI which will do what you need. Alternatively, you could use WPKG (also mentioned in the WIKI) which can run commands and system startup.

What's wrong with Windows Movie Maker then

It is possible to do silent installs of SIMS using the executables in the SIMSSetups folder. It is also possible to wrap these up in an MSI and deploy using Group Policy. Try looking on SIMS SupportNet for further details.

The trick is to stop all the exchange services before shutting down.

Daniel Petri has a good guide to transferring FSMO roles as well as loads of other useful stuff.

Granting everyone write access to a folder under Program Files might be a problem for those using Software Restriction Policies to prevent students launching unauthorised executables/scripts. I would suggest you move the cache to a folder on the root (eg c:\GoogleEarthCache), or possibly the all users application data folder (C:\Documents and Settings\All Users\Application Data) and set the necessary permissions.

It's a bit of an embarassment really. When I wrote it, I decided it should be able to do ANYTHING! All configuration is stored in an external XML file. It can map drives and printers, copy files/folders install MSIs, modify the registry, run executables etc. Each action can be assigned to a User, Group, Site, Location (OU) or Workstation. This means I can assign printers based on the location of the PC. Loads of the code therefore is for reading stuff in from the XML file and making sense of it. It's worked well and is in use in lots of sites, but I'm seriously thinking about starting over. I'm goint to learn PowerShell first though. Isn't timesync automatic anyway?

How about 'pimp my logon script' Mine's already several hundred lines long and XML driven...

BTW You can find the uninstall string for any app from the windows registry HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall then do a search for the app you want to uninstall. The key entry is UninstallString. I've seen some apps with a SilentUninstallString (perfect). If it's of the form 'MSIEXEC /X {GUID}' then just add /q to make it quiet and /noreboot to suppress reboots. For full MSIEXEC syntax, do MSIEXEC /?

The following did it for me V5 BTW MsiExec.exe /X{09C6BF52-6DBA-4A97-9939-B6C24E4738BF} /q /noreboot MsiExec.exe /X{C12953C2-4F15-4A6C-91BC-511B96AE2775} /q /noreboot MsiExec.exe /X{FF11005D-CBC8-45D5-A288-25C7BB304121} /q /noreboot

True, but some managed software (yes, I do machine assigned installs as well) seems to needs to access to the source MSI when run for the first time on a new profile (e.g. Office first run which sets up some user registry stuff I think). I think this is 'self repair'! In theory, all MSI's are cached in %SystemRoot%\Installer, but as I said, when I tested, at least one piece of software want to go back to the source, and presumably in the security context of the logged on user because SRP blocked it.

As ChrisH has pointed out, the \\(fqdn)\sysvol (eg. \\your.domain.name\sysvol) entry should cover logon scripts, unless you are using the old fashioned ones under NETLOGON. If so, then you might need to add extra exemptions on a per DC basis, I'm not sure. If you are using NETLOGON and don't want to add individual exemptions per DC, you could try \\your.domain.name\netlogon, which works if you browse to it.

OK, testing with SRP complete. I tried removing LNK from the lsit of extensions in the SRP for students, but shortcuts still failed. It turns out there was a machine based SRP in effect. Now I did not set this up so I assume it is there as a local machine policy in XP. The machine based SRP extension list was taking priority which meant that LNK files were still being blocked. I created my own machine based SRP and applied to an OU which covers all PCs that students will use, and removed LNK files. Bingo In summary then here's my setup... 1 - Machine based SRP with LNK removed from extension list (otherwise no changes to defaults) 2 - Users based SRP as follows... Disallow all software by default Remove LNK files from extension list Default exemptions are sufficient to allow software installed under C:\Program Files to execute (limited users cannot write here) Add exemptions for logon scripts \\(fqdn)\sysvol Add exemptions for managed software installs \\(servername)\install Add exemptions for network apps M:\ Add exemptions for an local apps not running from C:\Program Files (NB - Be as precise as possible!) The only thing I have not done is a comprehensive analysis of the permissions on C:\WINDOWS to find any locations that limited users might have write access to e.g. C:\WINDOWS\TEMP. If these exist, then they would need locking down with additional exemptions.

Cool. Does that mean it is no longer an InstallScript MSI and therefore does not need ISSCRIPT?

Dan, I don't get it... The driver I downloaded from the Promethean web site (ver 3.0.5) IS an MSI and I've deployed it fine. Still have to do the manual fix though. Can you tell me what you are changing in the 'new' MSIs?

Assuming you bought this from RM then you can get quite good support from their web site (many docs on installation etc.) and their telephone support. I've always found the successmaker support team to be really quite good. I too have an MSI for the client install. Not sure now if it's a repackage or a wrapped up silent install. I do know the sucksass maker pinches the file associate for WSF (should be for Windows Script Files) which buggered up my logon script!

I need to do more testing. I've been re-reading the SRP reference on technet and noticed the following things 1 - Avoid environment variables as they can be redefined to point to a different location 2 - If .LNK files can be excluded from the list of extensions which are checked, then the executable will still be subject to the SRP. This would mean that the user profile would not need to be exempt from the restriction.