Windows 10 slow running performance when joined an AD and using an AD-Account












1














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?










share|improve this question
























  • 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 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 at 8:36












  • Also nothing special at network traffic (or i didn't discovered it)
    – Hans Martin
    Dec 14 at 8:48
















1














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?










share|improve this question
























  • 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 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 at 8:36












  • Also nothing special at network traffic (or i didn't discovered it)
    – Hans Martin
    Dec 14 at 8:48














1












1








1


1





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?










share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 14 at 7:28









fixer1234

17.7k144581




17.7k144581










asked Dec 14 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 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 at 8:36












  • Also nothing special at network traffic (or i didn't discovered it)
    – Hans Martin
    Dec 14 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 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 at 8:36












  • Also nothing special at network traffic (or i didn't discovered it)
    – Hans Martin
    Dec 14 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 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 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 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 at 8:36














Also nothing special at network traffic (or i didn't discovered it)
– Hans Martin
Dec 14 at 8:48




Also nothing special at network traffic (or i didn't discovered it)
– Hans Martin
Dec 14 at 8:48










1 Answer
1






active

oldest

votes


















0














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!






share|improve this answer





















    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
    });


    }
    });














    draft saved

    draft discarded


















    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









    0














    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!






    share|improve this answer


























      0














      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!






      share|improve this answer
























        0












        0








        0






        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!






        share|improve this answer












        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!







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Dec 18 at 14:13









        Hans Martin

        62




        62






























            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            flock() on closed filehandle LOCK_FILE at /usr/bin/apt-mirror

            Mangá

            Eduardo VII do Reino Unido