ajbritton

AutoIt: IMHO one of the coolest things I ever found on the net.

To run the whole admin bar under alternate credentials would be simple enough by utilizing the RunAs command or options on a shortcut. I was thinking more along the lines of having the ability to run the bar at limited user level and only elevate when an app is launched. Each app could be configured to either use a default account defined for the whole bar or a specific account explicitly defined.

Something similar happened to me and it turned out that I had configured the Smarthost setting on the old Exchange server (instead of configuring an SMTP connector!). This meant that instead of making SMTP connections to the new server, it went straight to the ISP SMTP relay which, of course, could not locate the new Exchange server. I took the Smarthost setting out and off it went.

The other way of doing this without all the code (and I'm certainly not saying this is a better way. It's just an alternative), is as follows; 1 - Create a dedicated policy to map the drive for the particular group 2 - In the policy, create a simple script to map the drive 3 - Assign the policy to the required OU and then modify the default filtering by removing Authenticated Users and adding in the group that you want to have the drive One advantage of this method is that if the group is renamed, the drives will still be mapped, whereas with the long script, it will fail. As I said, not a better solution, just an alternative.

How about adding the option to execute these utilities with elevated permissions. This could be achieved using RUNAS or PSEXEC. That would mean that you could operate as a normal user and use network admin rights when appropriate (best practise).

Use ROBOCOPY. IIRC, the basic syntax will only overwrite older or changed files. I've used this many times in startup/logon scripts for syncing folders full of shortcuts from server to desktop.

The script presumably 'does' something on the PC when it runs. Is it not possible to have the script 'detect' the status of the PC to decide if it needs to run or not? Failing that, I would tend to write an entry in the registry rather than to a file but that's just down to personal preference.

Better sign myself up as I'm over the hill!

If this is your first software roll-out with GP then I would say the best advice is to test first. There are several ways to do this. You could create a complete test environment with servers and clients either using physical hardware or virtual machines, but this is probably overkill. I would create a 'Test' OU and move the computer account for a test PC into it. Create your policy and configure it to roll out the required MSI and then link the policy to the Test OU. Reboot the test PC and the software should be installed. Check it thoroughly. Reboot the PC several times and log on as different users to make sure the software behaves as you would expect. Once you are happy with this you are ready to look at rolling out. Depending on how long an install takes and how many PCs you are rolling out to, you may need to do a staged roll-out. If you have a large number of PCs and you assign the policy to them all at the same time, then they will all attempt to install on the next boot cycle. This may cause network problems and lots of PCs boot simultaneously (eg in a suite). To avoid this, either assign the policy to OUs containing smaller numbers of computer accounts or do 'policy filtering' based on group membership. To do this, you create an 'app' group and use it to filter the application of the policy. You can then add the computer accounts to the 'app' group a few at a time over days or even weeks until the software is rolled out to all PCs. Sahmeepee's point about using DFS is well made. When you have lots of GP assigned software, moving the installation share point can be a real nightmare. I hope this helps.

It's just a thought but maybe EduGeek could work together with Becta on this. A joint Becta/EduGeek mark/award might look more impressive to prospective purchasers. @contink: I do think there needs to be the repository for install info, but unless someone chips away at the problem it will only grow.

@daveyboy: While I like 2Simple software and agree that they are lovely people, I have to say that their software design is not always bang on and their MSI authoring is a bit basic. At least one title tries to create temporary files under C:\Program Files\... Some write to INI files in %WINDIR%. From what I remember, the INI settings are stored as files rather than INI settings in their MSIs. Yuck. @contink: From my POV, the idea behind the EduGeek mark or award would be to try to make the other software providers think about their own application design and delivery mechanisms. Surely the point is that we should not need to maintain a knowledge base of this stuff. All apps should be follow Microsofts application guidelines and be delivered with properly authored MSIs. Hand awards to those who get it right and name and shame those who don't. It's hardly rocket science after all.

Suggested this yonks ago (http://www.edugeek.net/forums/showpost.php?p=95683&postcount=20) and I still think it's an excellent idea. It would be great to present the first set of awards or marks at BeTT next year perhaps.

This is normal behaviour. As the curric domain now 'trusts' the admin domain to authenticate user accounts, admin users can potentially access resources in the curric domain and this includes logging on to the computers. I know of no way around it, but in theory you could create a startup script (or a custom policy) which sets the necessary registry settings on curric PCs to ensure the curric domain is the default entry and even to hide the 'log on to' box.

Those suggestions look interesting. Thanks HodgeHi and Webman.

Another vote for DaemonTools. I've had v4 installed on a couple of PCs and never noticed any adware though..

... and if that 'talk through' wasn't quite detailed enough, there is a guide to the various options for profiles and associated options on the wiki here

I really hate myself for feeling that I have to point this out, but 'technically' the computers 'container' is not an OU! It behaves slightly differently and IIRC, it's not possible to apply group policy directly on it. For this reason alone, I've always created specific OUs to contain member servers' computer accounts.

I think that tech_guy meant to say "C:\Program Files\Microsoft SQL Server\Backup" \\fs2\c$\temp * /S /E When you need to specify a file path that includes a space on a command line, the individual parameter should be enclosed in double quotes.

I tend to agree with russ_tech. You need to delegate the necessary rights on a OU which contains the student user accounts. If you make staff 'account operators' then they will be able to manage all (except admin) accounts. IIRC you need to go into AD Users & Computer, right click on the OU containing the student accounts and choose the 'delegate ...' option.

Backing up the registry before editing is always good advice. Having said that, I'm sure most techs will happily make minor changes like this when they are confident that they are not dabbling in areas they don't understand. I think that this registry edit will probably be harmless, but then I don't know what software you have on your server. You can use regedit itself to 'export' the key you want to edit. If it all goes pear shaped you can then 'import' the registry fragment you exported to repair the damage.

Just wanted to point out that OUs cannot be used to assign rights/permissions as OUs are not 'security principals'. Groups is the way to go.

Excellent idea I was there on Wednesday and Thursday and it was good to chat to Chris, Ric and Tony. I had the added pleasure of attending a Data Protection for Schools seminar contributed to in no small way by our founding father. It was most truly weird to see him in a suit! I look forward to bigger and better things next year...

Must agree with those that repackaging to make MSIs is not a breeze. I've repackaged more than 200 education titles over the last few years (some with AdminStudio but most with Wise) and I would say that the breakdown of difficulty and time is roughly as follows; 15% - Trivial (30 mins to 1 hour) 45% - Moderate (1 to 2 hours) 35% - Difficult (1 to 2 days) 4% - Very Difficult (up to 1 week!) 1% - Not possible/practical My personal view is the SIMS .NET should not be re-packaged partly because of the issue with regular updates and partly due to it's relatively complex nature and .NET dependence. Having said that, here is a SIMS MSI creation utility. EDIT: I've looked at the SIMS MSI mentioned above and it does appear to be a partially repackaged installation. I would suggest very thorough testing before using in a production environment.

I too saw far more XP than Vista at BETT. The big companies and PC vendors seemed to have more Vista on show. ... and I wish I had a pound for every time I heard someone talking about replacing Vista with XP. The report on ZDNet (http://news.zdnet.co.uk/software/0,1000000121,39292043,00.htm) made me laugh. I've not heard anyone say they are 'committed' to Vista, least of all a school!

Wrong file extension?