Windows 10 slow running performance when joined an AD and using an AD-Account
We recently updated our teams infrastructure to Windows 10 within an AD.
Everything works fine except:
We're observing slow performance in some situations. First observed was it as our Post-Compiling Powershell skript within VS2017 ran slower than below Windows 7. Google was also not helpful - but by now we hadn't the time to investigate further. Now recently we updated our CI build farm, too (TeamCity as CI Server). There we saw increasing build times by over 100% - a build for reference took 7m33s before the upgrade, after it stays at 17m05s.
Research here at StackExchange and google were not expressive.
A little more research brought us the finding that if we run the Agent with an local account on the machine (still in AD) we're getting build times around 8m50s.
The buildjob contains different MSBuild steps, nUnint runner and some powershell steps. No network activity - all is done locally on the agent. One MSBuild step took previously 36s and now 1m02s. Same with the NUint step - 30s vs 1m24s (all with the AD-User).
Any suggestion where the problem is?
windows-10 performance windows-domain
add a comment |
We recently updated our teams infrastructure to Windows 10 within an AD.
Everything works fine except:
We're observing slow performance in some situations. First observed was it as our Post-Compiling Powershell skript within VS2017 ran slower than below Windows 7. Google was also not helpful - but by now we hadn't the time to investigate further. Now recently we updated our CI build farm, too (TeamCity as CI Server). There we saw increasing build times by over 100% - a build for reference took 7m33s before the upgrade, after it stays at 17m05s.
Research here at StackExchange and google were not expressive.
A little more research brought us the finding that if we run the Agent with an local account on the machine (still in AD) we're getting build times around 8m50s.
The buildjob contains different MSBuild steps, nUnint runner and some powershell steps. No network activity - all is done locally on the agent. One MSBuild step took previously 36s and now 1m02s. Same with the NUint step - 30s vs 1m24s (all with the AD-User).
Any suggestion where the problem is?
windows-10 performance windows-domain
Does the domain have any special GPOs (gpresult /r), and/or does it install any data loss prevention software? Do you observe any network traffic during the build? Maybe the domain account uses "folder redirection" so that all your data is kept on a fileserver?
– grawity
Dec 14 '18 at 8:26
Nothing special here - only a few gpos: Angewendete Gruppenrichtlinienobjekte -------------------------------------- GPO-Passwords GPO_WSUS-Agents GPO_AutomaticLogin GPO_DisableUAC GPO-DisableTelemetry GPO-DisableCortana GPO-LocalAdmins GPO-Printer GPO-OpenFirewallForRPC GPO-PowershellExecutionPolicy GPO_WSUS Default Domain Policy No Software is distributed on our automated agents nor are the user profiles are on a central server (everything runs local).
– Hans Martin
Dec 14 '18 at 8:36
Also nothing special at network traffic (or i didn't discovered it)
– Hans Martin
Dec 14 '18 at 8:48
add a comment |
We recently updated our teams infrastructure to Windows 10 within an AD.
Everything works fine except:
We're observing slow performance in some situations. First observed was it as our Post-Compiling Powershell skript within VS2017 ran slower than below Windows 7. Google was also not helpful - but by now we hadn't the time to investigate further. Now recently we updated our CI build farm, too (TeamCity as CI Server). There we saw increasing build times by over 100% - a build for reference took 7m33s before the upgrade, after it stays at 17m05s.
Research here at StackExchange and google were not expressive.
A little more research brought us the finding that if we run the Agent with an local account on the machine (still in AD) we're getting build times around 8m50s.
The buildjob contains different MSBuild steps, nUnint runner and some powershell steps. No network activity - all is done locally on the agent. One MSBuild step took previously 36s and now 1m02s. Same with the NUint step - 30s vs 1m24s (all with the AD-User).
Any suggestion where the problem is?
windows-10 performance windows-domain
We recently updated our teams infrastructure to Windows 10 within an AD.
Everything works fine except:
We're observing slow performance in some situations. First observed was it as our Post-Compiling Powershell skript within VS2017 ran slower than below Windows 7. Google was also not helpful - but by now we hadn't the time to investigate further. Now recently we updated our CI build farm, too (TeamCity as CI Server). There we saw increasing build times by over 100% - a build for reference took 7m33s before the upgrade, after it stays at 17m05s.
Research here at StackExchange and google were not expressive.
A little more research brought us the finding that if we run the Agent with an local account on the machine (still in AD) we're getting build times around 8m50s.
The buildjob contains different MSBuild steps, nUnint runner and some powershell steps. No network activity - all is done locally on the agent. One MSBuild step took previously 36s and now 1m02s. Same with the NUint step - 30s vs 1m24s (all with the AD-User).
Any suggestion where the problem is?
windows-10 performance windows-domain
windows-10 performance windows-domain
edited Dec 14 '18 at 7:28
fixer1234
17.9k144681
17.9k144681
asked Dec 14 '18 at 7:03
Hans Martin
62
62
Does the domain have any special GPOs (gpresult /r), and/or does it install any data loss prevention software? Do you observe any network traffic during the build? Maybe the domain account uses "folder redirection" so that all your data is kept on a fileserver?
– grawity
Dec 14 '18 at 8:26
Nothing special here - only a few gpos: Angewendete Gruppenrichtlinienobjekte -------------------------------------- GPO-Passwords GPO_WSUS-Agents GPO_AutomaticLogin GPO_DisableUAC GPO-DisableTelemetry GPO-DisableCortana GPO-LocalAdmins GPO-Printer GPO-OpenFirewallForRPC GPO-PowershellExecutionPolicy GPO_WSUS Default Domain Policy No Software is distributed on our automated agents nor are the user profiles are on a central server (everything runs local).
– Hans Martin
Dec 14 '18 at 8:36
Also nothing special at network traffic (or i didn't discovered it)
– Hans Martin
Dec 14 '18 at 8:48
add a comment |
Does the domain have any special GPOs (gpresult /r), and/or does it install any data loss prevention software? Do you observe any network traffic during the build? Maybe the domain account uses "folder redirection" so that all your data is kept on a fileserver?
– grawity
Dec 14 '18 at 8:26
Nothing special here - only a few gpos: Angewendete Gruppenrichtlinienobjekte -------------------------------------- GPO-Passwords GPO_WSUS-Agents GPO_AutomaticLogin GPO_DisableUAC GPO-DisableTelemetry GPO-DisableCortana GPO-LocalAdmins GPO-Printer GPO-OpenFirewallForRPC GPO-PowershellExecutionPolicy GPO_WSUS Default Domain Policy No Software is distributed on our automated agents nor are the user profiles are on a central server (everything runs local).
– Hans Martin
Dec 14 '18 at 8:36
Also nothing special at network traffic (or i didn't discovered it)
– Hans Martin
Dec 14 '18 at 8:48
Does the domain have any special GPOs (gpresult /r), and/or does it install any data loss prevention software? Do you observe any network traffic during the build? Maybe the domain account uses "folder redirection" so that all your data is kept on a fileserver?
– grawity
Dec 14 '18 at 8:26
Does the domain have any special GPOs (gpresult /r), and/or does it install any data loss prevention software? Do you observe any network traffic during the build? Maybe the domain account uses "folder redirection" so that all your data is kept on a fileserver?
– grawity
Dec 14 '18 at 8:26
Nothing special here - only a few gpos: Angewendete Gruppenrichtlinienobjekte -------------------------------------- GPO-Passwords GPO_WSUS-Agents GPO_AutomaticLogin GPO_DisableUAC GPO-DisableTelemetry GPO-DisableCortana GPO-LocalAdmins GPO-Printer GPO-OpenFirewallForRPC GPO-PowershellExecutionPolicy GPO_WSUS Default Domain Policy No Software is distributed on our automated agents nor are the user profiles are on a central server (everything runs local).
– Hans Martin
Dec 14 '18 at 8:36
Nothing special here - only a few gpos: Angewendete Gruppenrichtlinienobjekte -------------------------------------- GPO-Passwords GPO_WSUS-Agents GPO_AutomaticLogin GPO_DisableUAC GPO-DisableTelemetry GPO-DisableCortana GPO-LocalAdmins GPO-Printer GPO-OpenFirewallForRPC GPO-PowershellExecutionPolicy GPO_WSUS Default Domain Policy No Software is distributed on our automated agents nor are the user profiles are on a central server (everything runs local).
– Hans Martin
Dec 14 '18 at 8:36
Also nothing special at network traffic (or i didn't discovered it)
– Hans Martin
Dec 14 '18 at 8:48
Also nothing special at network traffic (or i didn't discovered it)
– Hans Martin
Dec 14 '18 at 8:48
add a comment |
1 Answer
1
active
oldest
votes
Found the solution. It was a combination of Windows 10, MSBuild and our company infrastructure.
TeamCity wraps the MSBuild call. This wrapper, or some windows component inside, tries to communicate with "akamaitechnologies" - a CDN know Microsoft uses it for telemetry. As our company network is behind a proxy the request need to timeout. At the domain user this timeout was surprisingly longer than on the local accounts. The solution (why at also worked on the old local account) was to activate the system Proxy. Know the request gets immediately a "denied" response from the proxy. Build times went down to normal times.
Thanks to anyone who tried to help me out at this problem!
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1383491%2fwindows-10-slow-running-performance-when-joined-an-ad-and-using-an-ad-account%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Found the solution. It was a combination of Windows 10, MSBuild and our company infrastructure.
TeamCity wraps the MSBuild call. This wrapper, or some windows component inside, tries to communicate with "akamaitechnologies" - a CDN know Microsoft uses it for telemetry. As our company network is behind a proxy the request need to timeout. At the domain user this timeout was surprisingly longer than on the local accounts. The solution (why at also worked on the old local account) was to activate the system Proxy. Know the request gets immediately a "denied" response from the proxy. Build times went down to normal times.
Thanks to anyone who tried to help me out at this problem!
add a comment |
Found the solution. It was a combination of Windows 10, MSBuild and our company infrastructure.
TeamCity wraps the MSBuild call. This wrapper, or some windows component inside, tries to communicate with "akamaitechnologies" - a CDN know Microsoft uses it for telemetry. As our company network is behind a proxy the request need to timeout. At the domain user this timeout was surprisingly longer than on the local accounts. The solution (why at also worked on the old local account) was to activate the system Proxy. Know the request gets immediately a "denied" response from the proxy. Build times went down to normal times.
Thanks to anyone who tried to help me out at this problem!
add a comment |
Found the solution. It was a combination of Windows 10, MSBuild and our company infrastructure.
TeamCity wraps the MSBuild call. This wrapper, or some windows component inside, tries to communicate with "akamaitechnologies" - a CDN know Microsoft uses it for telemetry. As our company network is behind a proxy the request need to timeout. At the domain user this timeout was surprisingly longer than on the local accounts. The solution (why at also worked on the old local account) was to activate the system Proxy. Know the request gets immediately a "denied" response from the proxy. Build times went down to normal times.
Thanks to anyone who tried to help me out at this problem!
Found the solution. It was a combination of Windows 10, MSBuild and our company infrastructure.
TeamCity wraps the MSBuild call. This wrapper, or some windows component inside, tries to communicate with "akamaitechnologies" - a CDN know Microsoft uses it for telemetry. As our company network is behind a proxy the request need to timeout. At the domain user this timeout was surprisingly longer than on the local accounts. The solution (why at also worked on the old local account) was to activate the system Proxy. Know the request gets immediately a "denied" response from the proxy. Build times went down to normal times.
Thanks to anyone who tried to help me out at this problem!
answered Dec 18 '18 at 14:13
Hans Martin
62
62
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1383491%2fwindows-10-slow-running-performance-when-joined-an-ad-and-using-an-ad-account%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Does the domain have any special GPOs (gpresult /r), and/or does it install any data loss prevention software? Do you observe any network traffic during the build? Maybe the domain account uses "folder redirection" so that all your data is kept on a fileserver?
– grawity
Dec 14 '18 at 8:26
Nothing special here - only a few gpos: Angewendete Gruppenrichtlinienobjekte -------------------------------------- GPO-Passwords GPO_WSUS-Agents GPO_AutomaticLogin GPO_DisableUAC GPO-DisableTelemetry GPO-DisableCortana GPO-LocalAdmins GPO-Printer GPO-OpenFirewallForRPC GPO-PowershellExecutionPolicy GPO_WSUS Default Domain Policy No Software is distributed on our automated agents nor are the user profiles are on a central server (everything runs local).
– Hans Martin
Dec 14 '18 at 8:36
Also nothing special at network traffic (or i didn't discovered it)
– Hans Martin
Dec 14 '18 at 8:48