Wednesday, July 20, 2011

"turn on" and "turn off" a GPO's effect automatically based on a time period

You might have a situation where you want GPOs to apply to a collection of computers – but only within certain time blocks.

Sure, you could manually link and unlink the GPO when the proper times come. But you’re too busy for that.

Instead, use PowerShell, and automate the task!


First things first. Make sure the policy refresh interval on the workstations is set small enough to apply the activated GPO settings during the times you want. Normally, computers update every 90 – 120 minutes. To use this tip, you might want to tighten up the refresh interval – just for this collection (like a Training room OU or Kiosk OU or something.) I wouldn’t recommend you do this for your whole population. Do this using the policy settings located at "Computer Configuration | Administrative Templates | System | Group Policy | Group Policy refresh interval for computers."

Where this came in handy was to activate and deactivate additional (outgoing) firewall rules – specifically for a classroom setup for specific classes.

To use, simply set up a scheduled task to LINK and UNLINK the GPOs as needed.


To Enable:

Powershell -importsystemmodules -command "& {set-gplink -name 'GPO_Computer_Classroom Outgoing Firewall' -target 'ou=classroom,ou=computer management,dc=yourdomain,dc=local' -linkenabled YES}"

To Disable:
Powershell -importsystemmodules -command "& {set-gplink -name 'GPO_Computer_Classroom Outgoing Firewall' -target 'ou=classroom,ou=computer management,dc=yourdomain,dc=local' -linkenabled NO}"

Tuesday, July 19, 2011

Uncover Memory-Related Bottlenecks



Memory is often the source of performance problems, and you should always rule out memory problems before examining other areas of the system. Systems use both physical and virtual memory. To rule out memory problems with a system, you should configure application performance, memory usage, and data throughput settings, and then monitor the server’s memory usage to check for problems.

Application performance and memory usage settings determine how system resources are allocated. In most cases you want to give the operating system and background applications the lion’s share of resources. This is especially true for Active Directory, file, print, and network and communications servers. On the other hand, for application, database, and streaming media servers, you’ll want to give the programs the server is running the most resources.
Here’s an overview of counters that you’ll want to track to uncover memory, caching, and virtual memory (paging) bottlenecks.


Issue: Physical and virtual memory usage
Counters to Track: Memory\Available Kbytes; Memory\Committed Bytes
Details: Memory\Available Kbytes is the amount of physical memory available to processes running on the server. Memory\Committed Bytes is the amount of committed virtual memory. If the server has very little available memory, you might need to add memory to the system. In general, you want the available memory to be no less than 5 percent of the total physical memory on the server. If the server has a high ratio of committed bytes to total physical memory on the system, you might need to add memory as well. In general, you want the committed bytes value to be no more than 75 percent of the total physical memory.


Issue: Memory page faults
Counters to Track: Memory\Page Faults/sec; Memory\Pages Input/sec; Memory\Page Reads/sec
Details: A page fault occurs when a process requests a page in memory and the system can’t find it at the requested location. If the requested page is elsewhere in memory, the fault is called a soft page fault. If the requested page must be retrieved from disk, the fault is called a hard page fault. Most processors can handle large numbers of soft faults. Hard faults, however, can cause significant delays. Page Faults/sec is the overall rate at which the processor handles all types of page faults. Pages Input/sec is the total number of pages read from disk to resolve hard page faults. Page Reads/sec is the total disk reads needed to resolve hard page faults. Pages Input/sec will be greater than or equal to Page Reads/sec and can give you a good idea of your hard page fault rate. A high number of hard page faults may indicate that you need to increase the amount of memory or reduce the cache size on the server.

Issue: Memory paging
Counters to Track: Memory\Pool Paged Bytes; Memory\Pool Nonpaged Bytes
Details: These counters track the number of bytes in the paged and nonpaged pool. The paged pool is an area of system memory for objects that can be written to disk when they aren’t used. The nonpaged pool is an area of system memory for objects that can’t be written to disk. If the size of the paged pool is large relative to the total amount of physical memory on the system, you might need to add memory to the system. If the size of the nonpaged pool is large relative to the total amount of virtual memory allocated to the server, you might want to increase the virtual memory size 

Sunday, July 17, 2011

Five tips for getting cable clutter under control


Does your server room look like it’s ready for some marinara sauce and a few meatballs? Turn your cable chaos into a manageable system by following a few simple steps.
Nothing is worse than a datacenter filled with a tangled maze of wires. Besides being unsightly, cable clutter can make it difficult to troubleshoot cable-related problems. Here are five of my favorite tips for taming that cable mess.

1: Multitask

One of the best ways to get cable clutter under control is to eliminate any cables that are not absolutely necessary. Of course, this is easier said than done. Since you probably can’t go through your datacenter and start unplugging cables, the next best option might be to multitask.
Sometimes, you can achieve the functionality of several cables with a single cable. To give you an idea of what I mean, I recently installed an IP-based video surveillance system in my datacenter. The system was designed so that each of the eight cameras required its own power supply (AC adapter). After spending a little bit of time on Amazon, I found a power supply that could provide power to four cameras. Granted, I still had to use a few power supplies, but I cut the total number of power supplies I was using by 75%.
I’ve also been performing cable multitasking through my KVM switches. Up until a few weeks ago, I was using KVM switches that required a keyboard, video, and mouse connection to every server. I replaced these outdated switches with a new model that uses only a video cable. On the end of the cable that connects to the server is a USB connection for keyboard and mouse input. However, there is no USB connection at the other end of the cable. All keyboard and mouse input is sent through the video adapter and then split out into a USB port at the end of the cable. What previously required three cables is now done through a single cable.

2: Use the shortest cables you can get away with

Another clutter-reducing trick is to make your own network cables. If you use pre-manufactured cables, you’re stuck using cables with standardized lengths. This can result in excessive cable in your datacenter. By making your own network cables, you can ensure that the cables are cut to exactly the required length. This can go a long way toward cutting down on cable clutter.

3: Label your cables

I also recommend investing in a good label maker and labeling all the cables in your datacenter, even if the purpose of a cable seems obvious. Having well-labeled cables can make it far easier to troubleshoot cable-related problems.
The reason it’s a good idea to label the cables that are used for obvious purposes is that troubleshooting a problem can sometimes run late into the night. I can’t speak for anyone else, but I tend to make a lot of stupid mistakes when I start getting tired. I have found that making things as idiot-proof as possible helps prevent dumb mistakes later on.

4: Use zip ties sparingly

I once worked in a place where a number of servers were arranged on a large metal rack (not a traditional server rack). The person who had done the setup used zip ties to secure the various cables to the rack. I have to admit that the person did a good job keeping all the cables nice and neat.
But eventually, one of the computers started having trouble communicating across the network. It turned out that the network cable had been zip tied too tightly and the RJ-45 connector at the end of the cable was being pulled loose. Replacing the cable meant cutting all the zip ties and then replacing them. Because the zip ties bundled cables for multiple machines, this turned out to be a big job.
There is a time and a place for everything, and sometimes zip ties do have a place in the datacenter. However, before you zip-tie a cable, consider the amount of work that will be involved if you ever have to replace the cable.

5: Bundle excess cable

Earlier, I mentioned using custom-made network cables to avoid having excess cable. Sometimes, however, excess cable is unavoidable. For example, the AC adapter for my wireless access point has a three-foot cord, but I need only about a foot of it. When you can’t avoid using a cable that is longer than you need, bundle the excess cord. In the case of the power cord for my wireless access point, I used a twist tab around the excess cable.

The pros and cons of tower, rack, and blade servers


The pros and cons of tower, rack, and blade servers

Takeaway: Scott Lowe goes back to basics with this overview of tower, rack, and blade servers to help you make an educated decision about the best option for your data center.
There are three main choices when it comes to buying a new server: tower, rack, or blade. Here are some of the pros and cons about each kind of server, as well as some of my experiences with each one.

Tower servers

Tower servers seem dated and look more like desktops than servers, but these servers can pack a punch. In general, if you have a lot of servers, you’re probably not using a bunch of tower servers, because they can take up a lot of space and are tough to physically manage since you can’t easily stack them on one another. In some cases as organizations grow and move to rack servers, conversion kits can be purchased to turn a tower server into a rack-mount server.
As implied, tower servers are probably found more often in smaller environments than anywhere else, although you might find them in point solutions in larger places.
Tower servers are generally on the lower end price-wise, although they can expand pretty decently and become really expensive.
Tower servers take up a lot of space and require individual monitors, keyboards, and mice or a keyboard, video, mouse (KVM) switch that allows them to be managed with a single set of equipment. In addition, cabling can be no fun, especially if you have a lot of network adapters and other I/O needs. You’ll have cables everywhere.
I don’t buy a lot of tower servers these days, but they still have a place. My most recent tower server purchase was to serve as my backup system running Microsoft Data Protection Manager 2010.

Rack servers

If you run a data center of any reasonable size, you’ve probably used a lot of industry standard 19″ wide rack servers. Sized in Us (which is a single 1.75″ rack unit), rack servers can range from 1U “pizza boxes” to 5U, 8U, and more. In general, the bigger the server, the more expansion opportunities are available.
Rack servers are extremely common and make their home inside these racks along with other critical data center equipment such as backup batteries, switches, and storage arrays. Rack servers make it easy to keep things neat and orderly since most racks include cable management of some kind. However, rack servers don’t really simplify the cabling morass since you still need a lot of cabling to make everything work — it’s just neater. I once worked in a data center in which I had to deploy 42 2U Dell servers into three racks. Each server had to have dual power cables, keyboard, video, and mouse cables and six (yes, six) network cables (six colors with each color denoting a specific network). It was a tough task to keep the cabling under control, to put it mildly. Because everything was racked, there was built-in cable management that made this easier.
Like tower servers, rack servers often need KVM capability in order to be managed, although some organizations simply push a monitor cart around and connect to video and USB ports on the front of the server so that they don’t need to worry about KVM.
Rack servers are very expandable; some include 12 or more disks right in the chassis and support for four or more processors, each with multiple cores. In addition, many rack servers support large amounts of RAM, so these devices can be computing powerhouses.

Blade servers

There was a day when buying individual blade servers meant trading expansion possibilities for compactness. Although this is still true to some extent, today’s blade servers pack quite a wallop. I recently purchased a half-height Dell M610 blade server with 96 GB of RAM and two six-core processors.
There is still some truth to the fact that blade servers have expansion challenges when compared to the tower and rack-based options. For example, most tower servers have pretty significant expansion options when it comes to PCI/PCI Express slots and more disk drives. Many blade servers are limited to two to four internal hard drives, although organizations that use blade servers are likely to have shared storage of some kind backing the blade system.
Further, when it comes to I/O expansion options, blade servers are a bit limited by their lack of expansion slots. Some blade servers boast PCI or PCI Express expansion slots, but for most blade servers, expansion is achieved through the use of specially designed expansion cards. In my case, the Dell M600 and M610 blades have three mezzanines. The first mezzanine consists of dual Gigabit Ethernet adapters. The remaining mezzanines are populated based on organizational need. In my case, our blades have a second set of Gigabit Ethernet adapters housed in the second mezzanine and Fibre Channel adapters in the third. If necessary, I could also choose to use mezzanine cards with four ports in some configurations. So, although the blade server doesn’t have quite the I/O selection of other server form factors, it’s no slouch, either.
When raw computing power and server density is the key drive, blade servers meet the need. For example, in my environment, I have a 10U Dell M1000e blade chassis that can support up to 16 servers. So, each server uses the equivalent of 0.625U of rack space. On top of that, the blade chassis holds four gigabit Ethernet switches and two Fibre Channel switches, so there is additional rack space savings since I don’t need to rack mount these devices to support different connectivity options. In addition, the blade chassis has a built-in KVM switch so I don’t need to buy a third party and cable it up.
Speaking of cabling, a blade environment generally has much less of it than tower or rack environments since a lot of the connectivity is handled internally. You’ll end up with a neater server room as a result.
Another point is adding a new server consists of simply sliding it into an available slot in the chassis. There is no need to rack a new server and deal with a bunch of new cabling. This small size makes heat dissipation a challenge. Blade chassis can put out a lot of heat.
From a cost perspective, blade servers require some initial infrastructure, such as the chassis, so the upfront cost is often higher than for servers of other types.

Bottom line

If you need one or two servers, a tower solution probably makes sense. If you need three to 24 servers or massive scalability, then rack servers are for you. When you go need more than 24 servers, I advise you to consider a blade solution to meet your data center needs.

Have we forgotten how powerful Group Policy is?


Have we forgotten how powerful Group Policy is?


Takeaway: In critical times for Microsoft, we may have underestimated this centralized management solution for Windows systems. IT pro Rick Vanover will try not to start a fight, but highlight a long-time strength from Microsoft.
These days, it seems that Microsoft is taking a lot of criticism from a number of different avenues. One thing is rather undeniable; Group Policy is a great solution for centralized management. Each time I find some new configuration item, I’ll go out on Twitter and say something rash like, “Group Policy is the best product that Microsoft has ever made.”
While it may be a quick-passing comment, the fact the remains that there are many configuration capabilities that Group Policy objects (GPOs) make possible. Further, there are built-in security aspects around the computer account that allow the policies (including network access) to be enabled or disabled. Group Policy as we have it now was first introduced in Windows 2000, some ten years ago. Sure plenty of agent-based system management products have come into the field, but some things are still just best addressed with Group Policy.
Part of the critique with Microsoft is that they aren’t addressing the computing experience of modern times. While they haven’t “won” the mobile phone operating system war, I do applaud the recent extensions of System Center Configuration Manager (SCCM) 2012 to include Android, Symbian, iPhone/iPad platforms, and oh yeah, Windows Phone 7 systems. This is big news for the traditional environment dealing with the influx of consumer devices, yet still able to meet organizational needs.
While SCCM is not Group Policy, the strategy is a welcome bridge to managing this inevitable mix of devices. At face value, some may dismiss this as irrelevant because users are able to do everything they need to do without the traditional internal IT service. Sure, the vocal minority of that class of user will be self-sufficient with their iPad and fancy phone, but they may not need to do any real work that would need a full, managed computing experience.