More and more people are #ProudToBeCertified with Microsoft

by Contributed | Apr 29, 2021 | Technology

This article is contributed. See the original author and article here.

The popular response to our call for stories at #ProudToBeCertified has been inspiring. Anyone who’s taken a certification exam knows that passing takes dedication and an intensive time commitment. That’s just one of the reasons why these personal stories are worth sharing. In the coming weeks, we’ll be highlighting how Microsoft Certification has encouraged and empowered so many people around the world.

The perks of certification

When you expand and maintain your career by getting Microsoft-certified, the opportunities that become available are enough to make anyone proud. It increases confidence, income, professional credibility, and happiness. A study by Pearson VUE found that 67% of technical professionals say certification builds confidence; about 35% of technical professionals say getting certified led to salary or wage increases; and 41% said they’re happier in their jobs.¹

Organizations also benefit from continuous learning. IDC has found that trained and certified teams responsible for core IT activities are almost 20% more productive than less proficient staff, with Microsoft-certified IT professionals performing 26% better across all roles than uncertified IT professionals with the same responsibilities.²

In other words, certification is a great investment in yourself, and in your team. It’s a game-changer. As Microsoft MVP and Microsoft Certified Trainer Heather Serverino said in her Proud to be Certified story, “I can’t imagine what my journey would have been like had I not started with that first Microsoft Certification.”

Microsoft Certification benefits

When you, your team, and your organization maintain a culture that celebrates learning and achievement, everyone wins. Certification supports a forward-looking culture that values up-to-date knowledge and a constant striving for the next, most useful capabilities, not only as proof of skills and expertise, but with real benefits to individuals and companies.

Microsoft Certification helps you:

• Get recognized. Build confidence and be recognized as a leader, unlock new opportunities, and share your credentials with your professional network.


• Get ahead. Stay ahead of the curve, increase your productivity, and take your career to the next level.


• Get hired. Certified technical skills help you prepare for job opportunities by proving to employers you have the skills they want.

Microsoft Certification helps your organization:

• Increase performance. Certified employees are more productive, more efficient in their roles, and bring more creative solutions to complex technical problems.


• Increase value. Organization’s benefits include improved productivity, faster troubleshooting, and fewer skills gaps.


• Increase the talent pool. By simplifying talent identification and recruiting through certification you make your screening process easier.

This is just the start

When you check out the #ProudToBeCertified videos and stories, you’ll see that certification is a continual and rewarding journey. You might even be surprised by the opportunities certification has provided for individuals around the world. IT Consultant, MVP, and Microsoft Certified Trainer Akah Mandela Munab said in his story that certifications “opened doors to a large community where I could share my ideas and help others on their Microsoft Certification path.”

This is the first in a series of posts where we’ll be sharing the personal stories, business benefits, and latest insights on creating and maintaining a personal attitude of continual learning. Plus, we’ll highlight how organizational culture encourages and supports the extra effort and time it takes for every team member to keep advancing.

Already certified? We want to hear from you – because we believe the more professionals who share their accomplishments, the more encouraged others will be to join Microsoft’s growing community dedicated to continuous improvement. You are our certification community. Now, it’s time to celebrate it.

Watch more #Proud to be Certified videos and submit your story as a video or post on Twitter, LinkedIn, or your preferred platform with #ProudToBeCertified.

Related posts:

• Are you proud to be certified? Share your story!


• Haimantika Mitra’s journey from student with no code experience to app-making intern

¹Pearson VUE, “2018 Value of IT Certification”

²IDC white paper sponsored by Microsoft, “Benefits of Role-based Certifications,” June 2020

Announcing a New Windows Server Container Image Preview

by Contributed | Apr 29, 2021 | Technology

This article is contributed. See the original author and article here.

Today we are very pleased to announce a new Windows Server base OS container image preview built from Windows Server 2022 with Desktop Experience. To try it out, on a Windows Server 2022 Insider Build 20344 as the container host, run this command to start:

docker pull mcr.microsoft.com/windows/server/insider:10.0.20344.1

The direct link of the image repo on Docker Hub is here https://hub.docker.com/_/microsoft-windows-server-insider/.  

Why did we build this new image?

There are 3 Windows Base OS container images today that nicely cover the broad spectrum of customer needs: Nano Server – ultralight, modern Windows offering for new app development; Server Core – medium size, best fit for Lift and Shift Windows Server apps; Windows – largest size, almost full Windows API support for special workloads. Nano Server and Server Core container image adoption has been steadily growing and widely used for a while. In the last year or so, we are also seeing uptake of the Windows image adoption. Meanwhile, in the Windows Container community on GitHub and through our Customer Support, we have received feedback regarding constraints when using that Windows base OS container image. For example,

• Windows server 2004 has IIS application pool connection limit of 10


• Windows Server Container – mcr.microsoft.com/windows should have been a Server OS Container

Some of the constraints are by design because that Windows container image is built from a full Windows Client edition and enabled to run on Windows Server. As we are committed to invest in the Windows containers business, we believe it is a right thing at this right time to build a new image based on a “full” Windows Server edition to enable more capabilities. “Full” in the sense that we choose to use the Windows Server 2022 with Desktop Experience edition. Some of you may refer this as “Server Core” + “Desktop UI” informally. That’s how this new container image was born and built. It will be added to all the relevant repos on Microsoft Container Registry (MCR) and Docker Hub pages. I should note, though this image is built from an edition with Desktop Experience, Windows containers today by design do not have GUI. That’s not changed with this new image.  

What’s the name again?

Windows containers by themselves are not stand-alone products. They are considered features of Windows Server. Whatever name we choose needs to show that connection but also avoid potential confusion or duplication. That leaves us limited room for creativity . As you can see, with the path on MCR, “mcr.microsoft.com/windows/server”, this image is referred as “Windows Server base OS image”, or just short like this, “Server base image”, or “Server image”.

What about this new image?

This new image will be available with Windows Server 2022 release only. For those of you who are using the Windows images from previous releases that are still in support such as Windows Server SAC v1809, SAC v1909, SAC v2004 and SAC v20H2, those images are not changed and have their respective support cycles. This new image is not available with those previous releases. We encourage you to adopt Windows Server 2022 and move to use this new Server image.

Here is a quick comparison between all the 4 images:

Note: 

* “Supported Version today” lists the Windows Server releases that the container image was or will be released and is or will be supported. For example, with the first row, it means, Nano Server image was released with Windows Server SAC v1809, v1909, v2004 and v20H2 releases and will be in Windows Server 2022 release. That list can change as some releases reach their end of support.

**In the release wave of Windows Server 2019 and SAC v1809, Nano Server container and Windows container images were only shipped as an SAC with 18 months support cycle. Based on customer feedback, last year we have extended Nano Server container in the SAC v1809 release to be supported for 5 years. This Windows container image currently will reach its end-of-life support (EOL) in May hence we will be sure to share the update on the extension in May before the EOL. On the other hand, Server Core container image in that release wave was shipped both as an LTSC and an SAC. In an oversimplified way, you can think all the 3 images released during Windows Server 2019 and SAC v1809 wave are now being made aligned to be supported for 5 years to Jan 2024. We understand this is a confusing topic. We’ll come back with details in future blogs.

What are the key benefits and capabilities of the new image?

Compared to the current Windows image:

• Size Smaller: slightly smaller, from 3.4GB down to 3.1GB.


• Performance and Reliability Improved: Over the years we have improved performance and reliability of the Server Core container images thanks to the large adoption internally and externally. This image inherits all the improvements from Server Core.


• LTSC Support from the get-go: we are planning to support this image as an LTSC with 5 years mainstream support.


• Server functionality: we are still validating so the list here is not complete but we expect this image will enable more Server scenarios/features.
  
  
  
  • IIS Connection: as mentioned earlier, there was a 10 connection limit. This new image should no longer have this limit. We have customers validating with their scenarios.
  
  
  • Web APIs e.g. Web Management Services (WMSVC): in that same GitHub issue related to IIS, it was reported this feature is not supported. We are yet to validate but we believe this should be supported.         
  
  
  
  


• Fuller API support
  
  
  
  • GPU Support: We announced GPU support back in April 2019 in this blog Bringing GPU acceleration to Windows containers, with this accomplishing GitHub page on setting up the demo: Virtualization-Documentation/windows-container-samples/directx at live . We are very glad to share GPU support is validated on this new image. Below is a screenshot:
  
  
  
  

OK, that’s interesting. How do I get started?

Step 1: Install a Windows Server 2022 Insider

To get started, you’ll need a Windows Server 2022 installation based on the Insiders preview build 20344. You can download the bits from the Insiders page here: Download Windows Server Insider Preview. Once you download the ISO (or VHD), create a new VM based on this image.

Step 2: Install Docker

Once you have a working Windows Server 2022 Preview deployment, follow this to install Docker:

Install-Module -Name DockerMsftProvider -Repository PSGallery -Force

Install-Package -Name docker -ProviderName DockerMsftProvider

Restart-Computer -Force

Once the machine is restarted, run ‘docker info’ to ensure Docker was correctly installed.

Step 3: Pull the new image

docker pull mcr.microsoft.com/windows/server/insider:10.0.20344.1

Step 4: Run the new image

docker run -it mcr.microsoft.com/windows/server/insider:10.0.20344.1 cmd

Here is a screenshot for your reference:

Note:

• On a Windows Server host, containers are by default run in the process-isolation mode. You can find more at this doc page Windows Server Container Isolation Modes.


• If you would like to try out on a Windows 10 machine, please follow the instructions here Use Containers with Windows Insider Program. Be sure to use the latest Insider release. For example, I used a Windows 10 21364 Insider build. On a Windows 10 host, containers are by default run in the Hyper-V isolation mode.

References:

• Use Windows containers with the Windows Insider Program


• Windows Server Insiders Community on Tech Community


• Windows Container community on GitHub


• Windows Server Base OS Image Insider Build on Docker Hub

Closing

It’s been such a great journey since we started working on making this new image early this year. Your feedback really propelled us on the direction and innovations. We are so excited to share this with the community. We may get it right or we may get it wrong. Fail fast if needed. But we are in !

As always, we love to see you try it out, and give us feedback. You can share your feedback at our GitHub community, or contact us directly.

Weijuan

Twitter: @WeijuanLand

Email: win-containers@microsoft.com

Finding process which sporadically locks the workstation

by Contributed | Apr 29, 2021 | Technology

This article is contributed. See the original author and article here.

Hi all,

A customer of mine recently reported an issue that some workstations sporadically lock while the user is working and asked if we could figure out the culprit. Here is the story.

First let me mention that Konstantin Chernyi, a Microsoft CE colleague from Russia, contributed greatly here. So credits also go to him (thanks, Konstantin).

Before we start you need to understand a few basics. A workstation is usually locked by calling the User32.dll function User32dll!LockWorkStation (https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-lockworkstation). There may be other options but most applications rely on this function. LockWorkStation creates the LogonUI.exe process to display the Logon Screen and the Lock Screen (if configured). It’s also important to know the Lock events can be traced using the Microsoft-Windows-WinLogon provider. You can get a list of all installed providers by running the command

XPerf.exe -providers i

XPerf is a good choice to narrow down this type of sporadic issue. It supports circular file mode, which means it can overwrite old events to keep the file size at a specified maximum (important for long runs). It can also capture the stack to support stackwalking, so we can see functions that processes call (if symbols are loaded). XPerf is part of the Windows Performance Toolkit, which in turn is part of the Windows Assessment and Deployment Kit (Windows ADK). You can download the ADK here: https://docs.microsoft.com/en-us/windows-hardware/get-started/adk-install.

In Windows 10, Windows Performance Recorder (wpr.exe) is built-in and could be an alternative to XPerf (https://docs.microsoft.com/en-us/windows-hardware/test/wpt/author-a-custom-recording-profile). In this blog, however, I’m going with XPerf.

1. Create the trace

I asked the customer to run the following command in an elevated command prompt on a client that was affected by the sporadic locks:

xperf -on proc_thread+loader+profile+interrupt+dpc+dispatcher+cswitch -stackwalk profile+cswitch+readythread -buffersize 1024 -minbuffers 256 -maxbuffers 256 -maxfile 256 -filemode circular -start wl -on microsoft-windows-winlogon -buffersize 1024 -minbuffers 256 -maxbuffers 256 -maxfile 32 -filemode circular

This starts two ETW sessions: A kernel trace with some kernel providers to capture process and thread creation, image load and unload events, CPU samples, and the stack. The output file should stay at 256 MB (-maxfile, -filemode circular). The second trace captures events of the Microsoft-Windows-WinLogon provider which includes the Lock event.

After that the customer created a scheduled task, which triggers on the lock workstation event (luckily, we have this predefined trigger) with a delay of 3 seconds. This task runs the command to stop the trace and merge the trace files.

XPerf -stop -stop wl -d %TEMP%Lock.etl

Note that the two subsequent “-stop” are not a mistake. Remember that we created two ETW sessions?

2. Analyze the trace

To open the Lock.etl file, I use Windows Performance Analyzer (WPA).  I originally worked with the Lock.etl file uploaded by the customer, but for this blog post I simulated this issue to avoid posting screenshots with customer data. The simulation was done by calling RunDLL32.exe User32.dll,LockWorkStation, which makes RunDLL32.exe the “evil” process.

In WPA, I started with the Generic Events graph. Here we can find the event providers we traced next to the kernel trace (in our case the Microsoft-Windows-Winlogon provider).

Taking a closer look, we can see that the Lock event is also part of the trace (Yeah, we caught the fish).  Now, as we learned earlier, we know that a workstation lock triggers the LogonUI.exe process so I tried to find the start of this process in WPA.  For this, I needed another graph: Lifetime by Process.

The image shows the LoginUI.exe process in the timeline. The call to the LockWorkStation function must have happened shortly before the LogonUI.exe process was created. To get rid of unnecessary information we Zoom to the area starting at approx. 3 seconds before and ending about a second after the start of LogonUI.exe. I highlighted those 4 seconds in the graph, right-clicked in the highlighted section and selected “Zoom”.

Somewhere in this section the call to LockWorkStation happens. The “Transient” process list showed five processes were started within those 4 seconds. But it’s possible that a process started earlier than this zoomed-in-view made the call to User32!LockWorkStation. The processes started before the beginning of the zoomed area, are grouped into the “Permanent” Lifetime.

To finally find the caller to LockWorkStation I need to search the stack of all running processes (Permanent and Transient) for the expression LockWorkStation. To do this, I added another graph to view the stack: CPU Usage (Sampled). This new graph automatically adopts to the zoomed timeline and only displays processes running in those 4 seconds.

Now it’s time to load the debug symbols to. Otherwise we cannot search for the function name. I made sure that my PC had an Internet connection and, in the menu bar of the Windows Performance Analyzer, I clicked Trace -> Load Symbols. It could take a while when symbols are first loaded. 

I highlighted the first line of the process table in the CPU Usage (Sampled) graph (to make sure to search all processes) and clicked on the small magnifier icon to open the search dialog. After that I clicked the three dots to expand the dialog and typed “LockWorkStation” into the field after “contains” (the query is constructed automatically so this box can be left empty).

Clicking “Find All” unmasked our culprit.

Rundll32.exe was quickly identified as the calling process. Handcuffs, conduct under escort. Case closed.