Tag Archives: lab

Patching Without an Internet Connection

Posted on by
Reply

In some organizations, allowing servers to have direct access to the Internet isn’t permitted. Or, it could be you have an isolated lab and need to patch your machines. WSUS is great, but not always possible to implement.

There are a couple of utilities available that help with this. The first is quite excellent, http://www.portableupdate.com/

The second one I haven’t personally used http://www.wsusoffline.net/

Either of these tools should get you patched, without needing to worry about Internet connectivity from your machines.

 

Link

In my last post, I talked about building a lab PC to learn Lync. In this post, I’ll talk about what software you can run, and some extras that you might want to add depending on what your learning goals are.

First up, you’ll need some software. Hyper-V Server 2012 is free, as is the brand-new Hyper-V Server 2012 R2. While 2012 R2 has some newer features, virtual appliances that are in Hyper-V 2008 R2 format can’t be imported directly into Server 2012 R2 – you have to first import the vm into 2012, then to 2012 R2. You might want to stick with 2012 and upgrade to R2 later.

You’ll need Lync if you’re going to set up a Lync lab. You can download Lync Server, Windows, and SQL trial software. If you’re looking for something more ready-to-go, try the pre-configured Test Drive environment. For everything else Microsoft, hit the TechNet Evaluation Center.

For something a little more complete, Tommy Clarke and Ståle Hansen have released the script that they use to build labs for the training they do.

If you beef your lab up and run System Center Virtual Machine Manager, Shawn Gibbs has an excellent blog on something called Service Templates. Service Templates allow you to quickly deploy lab or hosted environments. If you’re looking to easily experiment with different environments, this could be great for you.

While a couple of PCs or laptops can be great for clients, you can also use virtual machines. Windows 7 Ultimate and Enterprise can redirect both speaker and microphone audio. You might need to dive into the registry to enable it. Fire up regedit, and the key you want is

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\

Change fDisableAudioCapture = 1 to 0

When you launch your RDP client to connect to the vm, make sure you select Show Options, select Local Resources, Remote Audio Settings and configure the audio options to play and record from this computer:

Setting Remote Audio Playback and Recording

If you want to try out mobile apps, an inexpensive consumer access point or wireless router can help you out. Use this to create a wifi network for your lab, that connects directly to your Lync environment, without having to do any funky routing through your home network to get there.

Speaking of routing, Bhargav from Kemp Technologies has an excellent blog on using Windows Server as a router in your lab.  You can use a router to emulate a WAN, or you can use a router to stand in for a firewall. You won’t have the fun of dealing with access control lists, firewall rules, and content inspection, but at least your Lync servers will be in appropriate subnets.

For the real firewall experience around edge servers, you can use Forefront TMG, Vyatta, or you might also be able to find a decent small-office firewall on eBay.

If you want to work with phones, a small PoE switch is nice. If you want to work with enterprise features, you’ll need to get a switch with VLANs, LLDP support, and one that at least respects DSCP markings. The HP ProCurve 2600 series is great for this, there are a few 8 port PoE models that are fanless. You can also skip POE and use power adaptors, though some manufacturers charge way too much for these – check out 1, 2 and 4 port PoE injectors that you can find online instead, for a lot less. Plan your cable management well, you’ll have a lot of cables that will tangle themselves into knots as soon as you’re not looking.

If you’re using Lync Server Enterprise Edition in your lab, you can use DNS load balancing, however the only supported design is with a hardware load balancer in front of the web services on the front ends. One unsupported option is to have the Internal Web Services URL FQDN resolve to the IP of just one of your front end servers. No web services will work if that server is down and your server load will be heavier on the front end you’ve chosen, so don’t do this in production. In a lab environment, you’ll otherwise be able to work with Enterprise Edition as if you had the HLB in place.

If you want to learn about hardware load balancers, you’ll need to spend more money, right? No way – check out the websites for the major vendors listed on Microsoft’s Infrastructure Qualified for Lync page, many of them will offer demos or limited bandwidth virtual appliances for free.

And lastly, if you’re going to have all kinds of VMs running, you might want a bigger monitor. You can find some 27″, 2560 x 1440 resolution monitors from stores on eBay. While you may have never heard of the brands, they’re less than half the price of name brand screens of the same resolution. What you don’t get is some of the bells and whistles like multiple inputs, USB hubs, and on-screen display.

Building your lab environment

Posted on by
Reply

Trying to learn how to deploy and administer Lync in your live production environment is what I like to call a resume-generating event. It’s a great way to find yourself looking for a new job. Setting up a lab environment doesn’t have to be expensive or difficult.

You may be thinking that you need to hit eBay and drop a bunch of money on some gently used server hardware to equip your lab. The reality is that server hardware is the worst purchase you can make for your lab. Servers are full of top-quality scalability, redundancy, management, and resiliency bits that you just don’t need for a lab.  They also use a lot of power, and can be quite loud.

Somewhat better than a server is a workstation. Workstations may be cheaper than a server, but still aren’t quite the configuration we’re after. Often, workstations have high-performance components that are expensive and unnecessary for a lab server. You don’t need super high resolution graphics, which most workstations will come with.

Well, what’s left? A regular PC, with a few carefully selected features and components, can do the job! Your lab won’t have the demands of a production system, and if some component fails you shouldn’t have anyone at your door asking when things will be back up. To be clear, I’m not talking about the latest Dell online special, as that’ll be aimed at the lower end of the market and won’t quite have the right features. What you’re after is a PC that you put together yourself (or have someone put it together for you). Some things to look for are:

  • The ability to go to 64G of RAM. This is a must – you’ll regret buying a new motherboard that only takes 32G.
  • 6 SATA ports is nice. If you wind up with less, you’ll likely need to buy an SATA card down the road to add more.
  • Buy a quiet case. Nobody likes loud, rattling computers. Make sure it has lots of empty drive bays.
  • Buy a liquid CPU cooler that exhausts using a large case fan. Bigger fans are quieter, and this type of cooler is only a few bucks more than the type with the screeching little fan.
  • Buy a passively cooled video card. No fan means no noise, and you don’t need screaming graphics performance – in fact if you RDP to your server and VMs, you’ll only need the card when you’re installing your OS.
  • At least one SSD. You’ll thank yourself when you’re not sitting around waiting for all of your machines to boot at once from your 5400 RPM econodrive. Windows, SQL, and Lync install a lot faster on an SDD than they do on a hard drive. If your virtual machines take too long to boot, services may not start and you’ll spend a bunch of time trying to troubleshoot, and then a bunch more time checking that every service started. (You can also start your machines in waves: DCs first, then SQL, then front ends, then edges, then everything else)
  • You will want a nice big HDD for backups, your ISO library, and VMs that don’t need SSD levels of performance. You can also boot from this drive if you don’t want a dedicated boot drive.
  • Buy extra NICs – get cheap ones! You don’t need performance, but one or two extra ports are nice to have. Some enthusiast motherboards come with two NICs, which is a great start.
  • For the CPU, check out prices for the various speeds available. Be frugal here. You don’t need to pay a premium for a tiny bit of extra performance. Make sure that the CPU you get fits both your motherboard socket and make sure your cooler is compatible.

If all of this is still too much for your piggy bank, here are some options for you: Put some VMs on SSD, others on HDD. You can build new machines on the SSD, then move them to an HDD. Over time, you can add more SSD space as your budget permits. There’s no problem with buying a smaller drive now and then adding another later.

  • Start with 32G of RAM. Make sure you buy modules sized so that you can add the other 32G later, without having to replace any modules.
  • You might have some older, lower capacity HDDs around. Don’t be afraid to use what you’ve got! You can always migrate VMs to different storage later.
  • If that’s still too much, you may find you get good results with adding some RAM and an SDD to a lower end PC. You likely won’t be able to move the RAM to new PC later, but you can most certainly move the SSD.

Next up, I’ll cover what you can do with your new lab environment.