zippo

Just a word of warning regarding the use of snapshots as a method of backing up Domain Controllers. Please remember that it is possible to really screw the Active Directory after restoring a snapshotted server. If the AD time stamps are out of sync for to long - the system will mark the server as having a degraded AD and that will effectively stop AD replication and updates. Whist not fatal - it can be a right pig to fix and involves the forced grabbing of FSMO roles and the forced removal of the server from the AD. Before adding it back in and re-allocating ther various roles.

From a practical point - I would include at least one x32 server. Why? Well most stations will be x32 OS and beleive me, x64 servers are a complete pain in the rear when it comes to print server duties. The x64 servers have x64 printer drivers built into them, which is fair enough. Whilst you can add x32 print drivers manually (to support your stations), it can be a complete nightmare trying to find x32 drivers for some printers - you can end up spending hours trying to source drivers for some oler legacey printers.

First things first - logon locally and check the IP address. Is it getting its address from the server or is it the 169.x.x.x address that Windows substitues whe it can't find a DHCP server. Check that the station has not had a manual DNS server configured (do this even if its getting its IP from the DHCP server). Finally can you actually get onto the internet or ping your servers by name.

It appears that SCHTASKS can probably do it as it allows a username and password to be provided. Also - /s switch sort of indicates that you could control this from the server itself SCHTASKS /Create /? SCHTASKS /Create [/s system [/u username [/P password]]] [/RU username [/RP password]] /SC schedule [/MO modifier] [/D day] [/i idletime] /TN taskname /TR taskrun [/sT starttime] [/M months] [/sD startdate] [/ED enddate] Description: Enables an administrator to create scheduled tasks on a local or remote systems. Parameter List: /S system Specifies the remote system to connect to. If omitted the system parameter defaults to the local system. /U username Specifies the user context under which the command should execute. /P password Specifies the password for the given user context. /RU username Specifies the user account (user context) under which the task runs. For the system account, valid values are "", "NT AUTHORITY\SYSTEM" or "SYSTEM". /RP password Specifies the password for the user. To prompt for the password, the value must be either "*" or none. Password will not effect for the system account. /SC schedule Specifies the schedule frequency. Valid schedule types: MINUTE, HOURLY, DAILY, WEEKLY, MONTHLY, ONCE, ONSTART, ONLOGON, ONIDLE. /MO modifier Refines the schedule type to allow finer control over schedule recurrence. Valid values are listed in the "Modifiers" section below. /D days Specifies the day of the week to run the task. Valid values: MON, TUE, WED, THU, FRI, SAT, SUN and for MONTHLY schedules 1 - 31 (days of the month). /M months Specifies month(s) of the year. Defaults to the first day of the month. Valid values: JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, DEC. /I idletime Specifies the amount of idle time to wait before running a scheduled ONIDLE task. Valid range: 1 - 999 minutes. /TN taskname Specifies a name which uniquely identifies this scheduled task. /TR taskrun Specifies the path and file name of the program to be run by this scheduled task. Example: C:\windows\system32\calc.exe /ST starttime Specifies the time to run the task. The time format is HH:MM:SS (24 hour time) for example, 14:30:00 for 2:30 PM. /SD startdate Specifies the first date on which the task runs. The format is "mm/dd/yyyy". /ED enddate Specifies the last date when the task should run. The format is "mm/dd/yyyy". /? Displays this help/usage. Modifiers: Valid values for the /MO switch per schedule type: MINUTE: 1 - 1439 minutes. HOURLY: 1 - 23 hours. DAILY: 1 - 365 days. WEEKLY: weeks 1 - 52. ONCE: No modifiers. ONSTART: No modifiers. ONLOGON: No modifiers. ONIDLE: No modifiers. MONTHLY: 1 - 12, or FIRST, SECOND, THIRD, FOURTH, LAST, LASTDAY. Examples: SCHTASKS /Create /S system /U user /P password /RU runasuser /RP runaspassword /SC HOURLY /TN rtest1 /TR notepad SCHTASKS /Create /S system /U domain\user /P password /SC MINUTE /MO 5 /TN rtest2 /TR calc.exe /ST 12:00:00 /SD 10/20/2001 /ED 10/20/2001 /RU runasuser /RP SCHTASKS /Create /SC MONTHLY /MO first /D SUN /TN game /TR c:\windows\system32\freecell SCHTASKS /Create /S system /U user /P password /RU runasuser /RP runaspassword /SC WEEKLY /TN test1 /TR notepad.exe SCHTASKS /Create /S system /U domain\user /P password /SC MINUTE /MO 5 /TN test2 /TR c:\windows\system32\notepad.exe /ST 18:30:00 /RU runasuser /RP * SCHTASKS /Create /SC MONTHLY /MO first /D SUN /TN cell /TR c:\windows\system32\freecell /RU runasuser

I think there is a flaw in your logic somewhere .. surely copying the desktop and start program shortcuts down to each machine will actually increase your network bandwidth? Where are you copying this to? If you have a dedicated directory structure (not in the users local profile), then you could use a GPO to set the local directory ACL's and then ther won't be a problem with copying. The downside would of course be that the users would have r/w access, but if its cleared and re-copied each time the process runs - I doubt if it would be a problem. But, I would still suggest that you put the desktop and start menu on a server, I can't see it having that a big of a system load.

Quite honestly sometimes buying something that just makes life easier is a good investment. Sure you can do things manually using CLI, its true for just about everything IT releated. I guess some people just love maintaining their core mode 2008 servers. I even expect some people install core mode just because they have to manage it using a CLI and powershell scripts! Just makes the magic of what you do even greater ... and your bosses stand in awe of your abilities! As you can probably guess, my IT management views are firmly in the "lets make it as easy as possible" court! Before anyone shouts - this reply is firmly tounge in cheek!

Firstly make sure all of your switches have the most upto date firmware installed. You could try reconfiguring the core switch manually - but you really need to buy Procurve Manager. I think that you can download a demo version - but to do everything you seem to want, you probably need to buy the full version.

Be very very careful running chkdsk - if you suspect a hard drive corruption it can do some very nasty things - one exapmple is stripping off all you ACL's for instance. Look at your system event log really carefully looking for disk errors - normally reported as SCSI type issues. If its a RAID system, check that it is'nt degraded or in rebuild. Certainly never ever run chkdsk whan a raid is degraded or rebuilding - you could do terminal damage.

The GPO Results wizard is good - but it lets you down when it comes to what is really happening at the PC. You need to run MMC with the Resultant Set of Polict (RSoP) snap-in. You can run this remotely - ie selecting the station and logged on user when you run the gather data wizard. It shows you the policies that have been processed - an indication of errors and the winning policy for each setting. But rather than simply modelling the result - it shows what is really happening. Quite honestly an invaluable tool in sorting out GPO related issues.

you could try running the process with elevated permissions using the runas command - The command line switches are (pulled from Microsoft) Runas Allows a user to run specific tools and programs with different permissions than the user's current logon provides. Syntax runas [{/profile|/noprofile}] [/env] [/netonly] [/smartcard] [/showtrustlevels] [/trustlevel] /user:UserAccountName program Top of page Parameters /profile : Loads the user's profile. /profile is the default. /no profile : Specifies that the user's profile is not to be loaded. This allows the application to load more quickly, but it can also cause a malfunction in some applications. /env : Specifies that the current network environment be used instead of the user's local environment. /netonly : Indicates that the user information specified is for remote access only. /smartcard : Indicates whether the credentials are to be supplied from a smartcard. /showtrustlevels : Lists the /trustlevel options. /trustlevel : Specifies the level of authorization at which the application is to run. Use /showtrustlevels to see the trust levels available. /user:UserAccountName : Specifies the name of the user account under which to run the program. The user account format should be user@domain or Domain\User. program : Specifies the program or

use the MMC resultant set of policy snapin on the station with the problem to determine the GPO's being applied. The RSoP tool is invaluable in terms of sorting out what is actually happening at the station. You can see if there are any errors or conflicts, but most importantly you can see the winning GPO that is being applied and what values are being set.

Well sort of - but there are a lot of applications out there disributed as MSI's that you can't use GPO software installation with - mainly because they don't exactly follow the rules. Next question - pretty obviosuly you installed whilst logged on as some soft of admin user. Could the problem be due to software installation permissions? Perhaps you could try a different track - and use one of the free package building packages to re-create the MSI

Not all MSI's allow silent installs - which prevents them installing using GPO's. Suggest that you try running the MSI under a command box - the /a and /qb switches should be tried (/a is admin install, while /qb is quiet basic install) If at any point the full application installation dialogue boxes appear requestin input - then I'm afraid you can't install it using that msi file.

Its probably one of two things (1) Firewall as already stated (2) Conflicker It is very common when installing clean PC's for them to get infected the moment they get connected to a network. It just takes one infected machine on your system and - wham ... new machine screwed.

First job was technical support at RML back in the days when they were behind Tesco's down the Coley Rd in Oxford. It was all 380Z's and I started before 5.25 or 8" floppies were available. Everything loaded from cassette tape in those days. I had two telephones - if the red one rang I had to answer it quick because it was likely to be from ILEA! Never been employed by a school as such - but have remained in the educational IT game for the last 26 years - which probably beats most of you. Oh - 52 YOA and always on the technical side.

From the horses mouth ..... Announcement on the future of Becta - Becta

The problem I see with this route is that this solution actually gives the selected staff complete control over all accounts, including admin accounts and other staff members. Not sure if this is a good thing.