IMPORTANT ANNOUNCEMENT FOR OUR READERS!
AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!
We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!
Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.
If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.
NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!
As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!
Hi everyone, Randolph Reyes (Randy) here with another blog contribution. In this particular engagement, I was working doing an Active Directory Offline Security Assessment (awesome delivery), and one employee with knowledge of using Windows Performance Toolkit stopped me on my way to lunch.
Customer: Can we see how long takes an employee to type their user name and password?
Randy: Thanks to WPT, the answer is yes.
The customer provided me with the trace from the last known time the user logged on to review…
So let’s get to it.
Boot to Post Boot Activity ended: 72.734 Seconds and 734 Milliseconds = 1 Minute and 12 Seconds
Now you might be saying to yourself, 1 min and 12 seconds is not too bad. What if I told you it was a SSD (solid state drive)? Would you consider this to be an optimal value? I’ve discussed optimal times in a previous post, “Becoming an Xperf Xpert Part 7: Slow Profile Load and Our Very First Stack Walk”
Since I don’t have an idea in how much memory, CPU or disk speed are in this particular host. I decided to check the specs.
In order to confirm that we are using a SSD (solid state drive) or similar, plus other specs expected to have faster boot up. We go to the tab Trace, then System and then General.
After doing some research about the hardware specs looks like this machine should be booting faster.
The major delay in the boot trace can be identified in the Winlogon Phase. Many operations occur in parallel during WinLogonInit, which on many systems, this subphase is CPU bound and has large I/O demands. Services like PnP and Power, network subsystem, Computer and User Group Policy processing, CAD (CTRL+ALT+DEL) screen and credentials delay. Good citizenship from the services that start in this phase is critical for optimized boot times.
To start we are going expand the System Activity graph group and we are going to add the graph Generic Events using table only.
After arranging the tables and the golden bar, the first issue detected was under Microsoft-Windows-Winlogon provider. The Task Name Display Welcome Screen aka CTRL+ALT+DEL was available to the user at 8.764 seconds of the trace. But he enters the combination in the keyboard at 18.055 of the trace.
Subtracting these times which get 9.295 seconds just waiting for the user to press CTRL+ALT+DEL.
Next issue detected in this particular trace is located under the Task Name Request Credential. Looks like the user entered the user name and password in 3 different times. First try was at 18.692 seconds of the trace at 39.59, again at 40.951 to 48.160 and finally at 48.958 to 51.012.
Looks like either the username, the password or one of the two were incorrectly typed and the access was denied.
At this point I explain the customer between the 9.295 waiting to press CRTL+ALT+DEL and 32.392 seconds with possible wrong typed credentials. This will probably be the reason of the long delay for the user.
We requested the user to log in again and the results are in the picture below…
Boot to Post Boot Activity end: 39 Seconds and 373 Milliseconds
At the end of this engagement customer was satisfied, not only because we helped them with security implementations for Active Directory, but also because we answered an important question for them… How to use the Windows Performance Toolkit to detect log in issues from the user.
Here are some other blogs for related topics by my good friend Yong Rhee and me.
Becoming an Xperf Xpert Part 8: Long Service Load, Never Jump to Conclusions
WPT: Updated version of “Windows Performance Toolkit” from Windows 10 Technical Preview ADK or SDK
List of Task Scheduler related hotfixes post SP1 for Windows 7 SP1 and Windows Server 2008 R2 SP1
Randy “Why, this keep happening to me” Reyes