Member_2_49692
asked on
Windows XP Speed comparison question
Hello,
I have been trying to cut a lot of fluff out of Windows XP. In our enviroment the machines are running slow and logging onto the network is taking a long time due to the number of policies we are applying at login that modify various regitry settings for various reasons.
What we want to do is take all of these policies away from the server at login and actually implement them in a master image and then reimage all the PC's with this image.
What I would like to know is if we create an image with all sorts of customizations and then deploy it ultimately would there be a speed difference between using Regedit or GPEDIT (and Modifying the Local Policy) to tweak the Operating System in terms of overall performance, bootup etc...
In other words if we apply all of our customizations through Regedit would that be faster then using GPEDIT on the local machine to apply a local policy of those customizations. I am looking to squeeze every possible bit of performance out of the O.S. and I am wondering if there is any difference. I am guessing the policy would be slower because the O.S. has to look through all the policy settings and apply on the fly versus it being hard edited into the system. But I want to know if anyone has a solid answer on this.
I have been trying to cut a lot of fluff out of Windows XP. In our enviroment the machines are running slow and logging onto the network is taking a long time due to the number of policies we are applying at login that modify various regitry settings for various reasons.
What we want to do is take all of these policies away from the server at login and actually implement them in a master image and then reimage all the PC's with this image.
What I would like to know is if we create an image with all sorts of customizations and then deploy it ultimately would there be a speed difference between using Regedit or GPEDIT (and Modifying the Local Policy) to tweak the Operating System in terms of overall performance, bootup etc...
In other words if we apply all of our customizations through Regedit would that be faster then using GPEDIT on the local machine to apply a local policy of those customizations. I am looking to squeeze every possible bit of performance out of the O.S. and I am wondering if there is any difference. I am guessing the policy would be slower because the O.S. has to look through all the policy settings and apply on the fly versus it being hard edited into the system. But I want to know if anyone has a solid answer on this.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
The policy list is huge and what we are thinking is this... If all users are going to be locked down with the same image with the same options and same permissions essentially.
We are using Zen imaging with a Novell network client on Windows XP machines.
The comparison I am trying to determine is taking all of the network policies that we can and duplicate them to a local machine policy or use a multitude of registry settings to accomplish the task
A good example would be we set a registry entry in the O.S. to force classic windows usage versus setting the local policy that does the same thing.
We would then make an image of this and then reimage all workstations with this image.
So when Windows boots is it faster for it to have the clasic menu setting predefined in the registry or for the O.S. to look at the local policy and see that we are forcing the classic menu ?
We are using Zen imaging with a Novell network client on Windows XP machines.
The comparison I am trying to determine is taking all of the network policies that we can and duplicate them to a local machine policy or use a multitude of registry settings to accomplish the task
A good example would be we set a registry entry in the O.S. to force classic windows usage versus setting the local policy that does the same thing.
We would then make an image of this and then reimage all workstations with this image.
So when Windows boots is it faster for it to have the clasic menu setting predefined in the registry or for the O.S. to look at the local policy and see that we are forcing the classic menu ?
If all users are going to be locked down the same why is the policy list huge. One policy applied at the domain is all that is required.
ASKER
What has happened is several things as to why our policies have gotten out of control....
We have the standard issue policies across the board that everyone is set for in the group policy on the server in Netware. We also have a bunch of policies that affect users but not administrators however after reviewing the policies locking down certain things across the board for both admins and users should have no negative affect on us admins as we do not use these objects / items anyways so it won't hinder us.
Basically what we are trying to do is two fold
1. reduce network traffic and time for policy to be applied to the pc during login and bootup
2. consolidate the policies so that we do not have all of these one off policies we have created over the years for deploying certain applications that require specific registry mods or folder mods.
So basically what I am asking is if we put as much as possible in the local group policy on our master machine, use sysprep and the make it an image to deploy on every workstation. In addition we then change all of those locally configured policies in the domain policy to " not configured" so that way the domain is not pushing down all these policy settings will that or will that not
A. Speed up boot time on the pc because it should (in my thinking) reduce the time for the policy to be applied to the workstation since it is local it does not have to wait to come down through the network
B. Cut down on network bandwidth being used to transfer all of those settings to over 1,500 workstations.
Does anyone have an idea how much bandwidth a whole policy comming down from the domain controller uses and am I correct in my line of thinking above ? (I have seen the machine slow down more with the more settings in the policies and policies added).
We have the standard issue policies across the board that everyone is set for in the group policy on the server in Netware. We also have a bunch of policies that affect users but not administrators however after reviewing the policies locking down certain things across the board for both admins and users should have no negative affect on us admins as we do not use these objects / items anyways so it won't hinder us.
Basically what we are trying to do is two fold
1. reduce network traffic and time for policy to be applied to the pc during login and bootup
2. consolidate the policies so that we do not have all of these one off policies we have created over the years for deploying certain applications that require specific registry mods or folder mods.
So basically what I am asking is if we put as much as possible in the local group policy on our master machine, use sysprep and the make it an image to deploy on every workstation. In addition we then change all of those locally configured policies in the domain policy to " not configured" so that way the domain is not pushing down all these policy settings will that or will that not
A. Speed up boot time on the pc because it should (in my thinking) reduce the time for the policy to be applied to the workstation since it is local it does not have to wait to come down through the network
B. Cut down on network bandwidth being used to transfer all of those settings to over 1,500 workstations.
Does anyone have an idea how much bandwidth a whole policy comming down from the domain controller uses and am I correct in my line of thinking above ? (I have seen the machine slow down more with the more settings in the policies and policies added).
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
KCTS,
Thinking about this I would think that if I thinned out the policy on the server and set the policy as local as much as possible that less data would be transferred through the network while it may be a miniscule savings of bandwidth aggragated I could see a difference am I wrong in this thinking that a smaller policy on the server would result in less data being transefrred ?
I am going to try setting up some port monitoring on the switches and test two different PC's I think this is the only way to find out for sure unless you have tried this before...
Thinking about this I would think that if I thinned out the policy on the server and set the policy as local as much as possible that less data would be transferred through the network while it may be a miniscule savings of bandwidth aggragated I could see a difference am I wrong in this thinking that a smaller policy on the server would result in less data being transefrred ?
I am going to try setting up some port monitoring on the switches and test two different PC's I think this is the only way to find out for sure unless you have tried this before...
ASKER
increased points to 500 so I can split it
ASKER
thanks guys. We tried setting up two seperate machines and in timing them between the two policies there was no consistency. One minute the machine that is hardset would be faster then it would be the one that is bringing down the policy. It kept going back and forth.
However we couldn't fully test this because for whatever reason the domain policy even when something was not configured it was overriding the local workstation policy that was set. Novell was contacted on this and have yet to get back.
However we couldn't fully test this because for whatever reason the domain policy even when something was not configured it was overriding the local workstation policy that was set. Novell was contacted on this and have yet to get back.
I don't think what you are suggesting is a sensible way forward. Better to rationalise the policies that are being applied and perhaps look at stramlining the policies and OU structure to make them more efficient.