Skip to content

Windows Lab Hydration Kit

Ebag333 edited this page Apr 19, 2019 · 7 revisions

Note: Links below do not seem to work in Chrome at this point in time. Use Internet Explorer or Edge to download.

Current URL

https://docs.microsoft.com/en-us/microsoft-365/enterprise/modern-desktop-deployment-and-management-lab

Alternate Lab: http://aka.ms/PublicHydration Note: This lab isn't recommended as it uses the older methodology of building the lab via MDT.)

Cheat sheet notes to the Lab

  • You don't have to import everything. Rename the folders and they won't get imported. There will be an error in Setup.exe as it tries to import it, this can safely be ignored.

  • (This seems to be resolved in newer versions) If you have less than 8 cores the CM1 server import will fail. Browse to the HYD-CM1 folder, search for *.xml, you will get two results. Edit both files in the same fashion: search for processors and change the line directly below this to a smaller number. The original line reads: <count type="integer">8</count>

  • Proper sizing of the VMs is important. I use 2 processors on CM1, everything else gets 1 processor. CM1 gets 3 GB of RAM, everything else gets 1 GB. If being sized for a larger test environment, those numbers will need to go up. Also you may need to bump those numbers up while testing (2 processors for the clients while re-imaging them, for example). I also turn off dynamic memory.

  • If you are leaving your lab running for long periods of time, you will find SQL will eat up all available memory and will cause the VM to run poorly or even crash. The solution to this issue is to open SQL Server Management Studio with admin rights, right click on the root node (reads CM1 on the SCCM server), click on Properties. Select the Memory page and set Maximum Server Memory to about 50-70% of your VMs assigned memory. For my server (with 3 GB) I set a 1 GB maximum server memory limit for SQL. Remember that Windows has a hard bottom limit of how much memory the OS needs, so make sure you have at least 512 MB (ideally 1 GB) free for the OS itself. If you don't give Windows enough system memory, it'll start swapping to the disk which is extremely slow. Also remember that the limit you set is the limit SQL uses for the databases and does not include SQL overhead. Expect SQL to use around .5-1 GB more than what you set.

  • If you do not import GW1 (the gateway server), none of your servers will have external access and they will quickly start shutting down after a few hours. This is a protection put into place by MS for licensing reasons. The easy work around to this is to add a second network adapter on each VM pointing to your external virtual switch. If you don't do this, then GW1 will have to be running to avoid this issue.

  • If this is being used internally and for testing, it can be beneficial to disable Defender (especially with VMs that are sized very small). To disable run gpedit.msc from a command line (or start menu), navigate to Computer Configuration -> Administrative Templates -> Windows Components -> Windows Defender Antivirus, and enable Turn Off Windows Defender Antivirus. Use this at your own risk as this disables any protection against malware/viruses on the system.

  • If the trial license on the servers expires (90 days), you can reset it by executing slmgr.vbs /rearm from command prompt. The clients use the evaluation version of Win 10 and will have to be rebuilt (or re-imported) when they expire.

  • For SQL, it's recommended to upgrade (not install) to the latest Developer edition. SQL will expire, and it's not easily re-armed as Windows is. Last checked the lab ships with SQL 2014, SQL 2017 is available. If SQL has already expired, you won't be able to start the service but it should still upgrade fine. You'll need to manually run the setup with the following command: setup.exe /ACTION=UPGRADE /SKIPRULES=Engine_SqlEngineHealthCheck