gshaw Posted July 11, 2008 Posted July 11, 2008 Putting these on our teaching machines (auto logon, generic machine account) to standardise the desktop experience but just wondering where people store theirs? Obv it goes in a network share but does anyone put them in SYSVOL or NETLOGON for replication purposes (gives some fault tolerance and distrubutes the load) or just lobbed on a general network share? Same again for redirected desktops \ start menus, I know folder redirection doesn't like the %LOGONSERVER% variable. Atm I've got a path like... \\domainname\SYSVOL\domainname\usersettings\desktops\teachpc (made the usersettings folder myself) Still testing this atm, seems to work OK apart from a userenv warning about profiles on a share with offline files turned on (not touching the settings on anything in SYSVOL so leaving as is for now!) Any suggestions \ tips much appreciated
elsiegee40 Posted July 11, 2008 Posted July 11, 2008 Our Pupil mandatory profile is in with the staff roaming profiles in the profiles share on the the 'Applications' Drive on the server.
powdarrmonkey Posted July 11, 2008 Posted July 11, 2008 When I last used mandatory profiles they were just in the profiles share in DFS. I don't see why SYSVOL would make it any faster.
elsiegee40 Posted July 11, 2008 Posted July 11, 2008 When I last used mandatory profiles they were just in the profiles share in DFS. I don't see why SYSVOL would make it any faster. Slowness is usually caused by the size of the profile rather than its location... I'll you refer to the small mandatory profiles thread!
gshaw Posted July 11, 2008 Author Posted July 11, 2008 I'm thinking more of redundancy... what if the file server goes down taking the profiles with it?
zag Posted July 11, 2008 Posted July 11, 2008 I've got mine on the main file server but its only a 2mb file. What I want to do is build a new dedicated profiles server (that has the staff roaming profiles on as well), I've got a 16gb SSD drive laying around so this could really help with the speed of logins but not tried it yet.
gshaw Posted July 11, 2008 Author Posted July 11, 2008 Yeah mine are only 1.75MB as well, the "applying computer settings" section takes longer than the "applying personal settings"
srochford Posted July 11, 2008 Posted July 11, 2008 Going way back into pre-history (ie Lan Manager and Windows NT 3.5) the "normal" practice was to put things you wanted to replicate into the netlogon share (because there wasn't anything else!) Old-timers like me, just carried on doing that - mandatory profiles go in the netlogon share still - but there isn't any need to do that and you can set up any replicated folder to do it. I can't see any reason not to have a share called "profiles" and put mandatory (and roaming if you want) in that location.
gshaw Posted July 11, 2008 Author Posted July 11, 2008 Profiles would be OK in NETLOGON then, so path like... %LOGONSERVER%\NETLOGON\profiles Should sort that out. How about the Start Menu \ Desktop (so every user has the same one), had aggro with that with both the environment variables and also in NETLOGON they did weird things about trusted zones and "are you sure you want to open this file" securuty warnings?
Richie1972 Posted July 11, 2008 Posted July 11, 2008 I've put ours on each machine (pushed out via MSI). It helps for when four or five IT suites logon at once or wireless laptops are used. Any time we update profiles, start menus, etc, we just repackage the MSI and push out via GPO
gshaw Posted July 11, 2008 Author Posted July 11, 2008 Hmm we had shortcuts locally on the PCs before, nto really keen on that idea but see your point with speeding up the profiles - how do people find they perform e.g. do you team the NICs on the DCs etc?
SYNACK Posted July 11, 2008 Posted July 11, 2008 Be careful that you do not put to much in the netlogon share, the replication system used can't handle large amounts of data and your neetlogon share will disappear into the ether with event log messages about replication failures.
gshaw Posted July 11, 2008 Author Posted July 11, 2008 I've got one Start Menu's worth of shortcuts, some desktop icons and one or two batch files and that's about it. I've put them in a folder under SYSVOL i.e. alongside the NETLOGON (scripts) folder rather than inside it, seemed to cause less aggro with the Start Menu that way. Mapped the profile via %LOGONSERVER%\SYSVOL\domain\usersettings\profiles Desktop via \\domain\sysvol\domain\usersettings\desktop Start Menu via \\domain\sysvol\domain\usersettings\startmenus Seems to work OK, direction goes through and maps the paths to the DC's name... so far so good Total file size is about 10MB, it should be able to handle that I'd hope
ajbritton Posted July 12, 2008 Posted July 12, 2008 I've put ours on each machine (pushed out via MSI). It helps for when four or five IT suites logon at once or wireless laptops are used. Any time we update profiles, start menus, etc, we just repackage the MSI and push out via GPO I was going to suggest something like this, but rather than use MSI, which requires certain skills, I would just use a startup scrtipt that ROBOCOPYs from the server to a drive on the PC e.g. ROBOCOPY \\servername\profileshare\mandatory C:\Profiles\Mandatory /e /purge (guessing syntax from memory, but this is a basic sync that only copies changes) You would also need to ensure the security on the C:\Profiles\Mandatory path was such that users could read and not write. This could be achieved in a number of ways (eg CACLS or GP) User accounts would then be set to use profiles from C:\Profiles\Mandatory\(profilename)
gshaw Posted July 12, 2008 Author Posted July 12, 2008 But then unless u do a compare between the profile on the PC and the one on the server you'd still be shifting the data across at each logon anyway?
ajbritton Posted July 12, 2008 Posted July 12, 2008 But then unless u do a compare between the profile on the PC and the one on the server you'd still be shifting the data across at each logon anyway? Not sure if you are referring to my 'robocopy' post but if so, ROBOCOPY is smart enough to only copy files that are different. It works this out by looking at things like date/size of the files. There will be a compare, but it is not byte for byte and does not take long.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now