The WSUS Product Team posted instructions on their Blog site describing how to install the WSUS 3.0 SP1 Role on a Windows Server 2008 SP2 server. This is for a scenario in which you have a Windows Server 2008 machine which does not already have WSUS installed, and you either already installed Service Pack 2. Once SP2 is in place, you can install WSUS as a role using the Server Manager console. Read their notes and comments for more details.
I was curious as to what topics or subjects I ramble about which gain the most "traction". To put it another way: which posts earn the most views. The results are interesting, to me at least. The top five (5) viewed posts, in order, are as follows:
Hits Subject
1787 Off-Topic: Gary Vaynerchuk is Crazy
883 Windows BAT Tip of the Week: ForFiles.exe
734 WSUS 3.0 API Samples Download
712 Patching WSUS 3.0 with KB954960
585 WSUS System Event 13001
What every want-to-be marketing goon desires is to be able to self-correct their efforts using statistical analysis. Gathering data, compiling it to produce patterns to show what's going on, and hopefully identify what to do next. I have to say that I'm completely confused. Hence the name "skatterbrainz". A good name indeed.
So, I'll leave it to you to let me know what topics or subject matter interests you most, and I will take that and do my very best to focus on that from here on out. Knowing what readers want will help me avoid distractions and diluted content. Otherwise, I will continue to ramble and wander aimlessly across the vast expanse of confusing wonders that crosses my mind at any given time of whenever. Ok, that last sentence was just dumb. Oh well.
So, should I blabber about WSUS? Windows Server 2008? Scripting? Off-Topic things? A mix of them? You tell me.
For various reasons, you may want to restrict certain configuration processes to a subset of your environment. The reasons vary widely. For example, to avoid doing something on servers or laptops, or only doing something within Terminal Server sessions. Depending upon the tools you have, or "use", within your arsenal at hand, you have an array of options at your disposal to effectively restrict, or "filter" your processing to only the conditions for which you want them to take effect.
Group Policy provides a useful feature that allows you to query environment properties at the time the policy objects are being parsed and applied. This can be at computer startup, at user logon, or during the periodic automatic refresh throughout the day. Login and Startup scripts can also leverage the use of queries against the environment to determine what actions to take. Where Group Policy can only query WMI repository data (hence "WMI Filtering"), scripts can obtain data from a variety of sources, including WMI, ADSI, and the registry, among others. Which path you take will depend upon your resources, time and comfort level. This short article is only intended to provide a few quick snippets as examples of each approach to illustrate what is possible, at the very least. You can obviously do MUCH more with a little time and tinkering.
Group Policy WMI Filtering
Rather than rehash how to use WMI Filtering with Group Policy Objects, you should read a few well-written articles:
If you haven't used WMI Filtering like this, be forewarned: BE CAREFUL to NOT overdo it! Parsing and processing group policies is already a bit resource intensive once you start going beyond the bare-bones settings provided by "Default Domain" and "Default Domain Controllers" policy settings. The more GPO's you create, and the more settings you configure (enable/disable) the more overhead is created during startups and logins for each computer and user. Plan and Test. Say that again until you turn blue: "Plan and Test", and I'm talking about an isolated environment, not your production environment!
That said, don't be afraid to explore WMI Filtering to enhance the effectiveness of your Group Policy configuration management efforts. I've seen some amazing things done with that approach. For example, borrowing some examples from the above linked sites (beware of code wrapping, should be on one line for proper use):
Example 1 - Check for running on Server Core:
SELECT OperatingSystemSKU FROM Win32_OperatingSystem WHERE OperatingSystemSKU = 12 OR OperatingSystemSKU = 39 OR OperatingSystemSKU= 14 OR OperatingSystemSKU = 41 OR OperatingSystemSKU = 13 OR OperatingSystemSKU = 40 OR OperatingSystemSKU = 29
Example 2 - Check for Windows Vista, Server 2008 or later (includes Windows 7, 2008 R2):
SELECT Version FROM Win32_OperatingSystem WHERE Version LIKE "6.0%"
Example 3 - Check for Laptop (using memory form factor indication):
SELECT * FROM Win32_PhysicalMemory WHERE FormFactor != 12
Scripting
Now, if you're a scripting nut (like me) and prefer writing code to building API-ish queries in a GUI interface (you can write them from a command line also, by the way, but that's for another day), you may want to know what can be done with things like KiXtart and VBscript programming.
KiXtart 4.6x provides an updated "macro" property named @ProductType, which returns the full text name of the operating system, such as "Windows Server 2008 Enterprise Edition". In addition, it provides the @TsSession and @InWin macro properties. @TsSession returns 1 (true) if the script is running within a terminal server session. @InWin returns 1 (true) if the script is running within an operating system based on Windows NT (anything after Windows NT, such as Windows 2000, XP, Vista, Windows Server, and Server Core). Combining these allows for incredible flexibility and potential for tailoring code processing to specific conditions.
Example 4 - Filtering with KiXtart Script:
$platform = Ucase(Trim(@ProductType))
if @InWin = 1
if InStr("SERVER", $platform) > 0 or InStr("DOMAIN", $platform) > 0
? "you are running on a server operating system"
$server_session = 1
$terminal_session = 0
else
$server_session = 0
if @TsSession = 1
? "you are running in a terminal session"
$terminal_session = 1
else
? "this is a non-server operating system, non-terminal session"
$terminal_session = 0
endif
endif
endif
Example 5 - Get Operating System information with VBScript and WMI
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2")
Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_OperatingSystem",,48)
For Each objItem in colItems
platform = objItem.Caption ' ex. "Microsoft Windows 7 Ultimate" or "Microsoft Windows XP Professional"
buildnum = objItem.BuildNumber ' ex. for Vista might be "6000", for Windows 7 might be "7022"
servicepack = objItem.CSDVersion ' ex. for XP might be "3", for Windows 7 might be null
os_type = objItem.ProductType ' ex. 1=workstation, 2=domain controller, 3=server
Next
If os_type = 3 Then
wscript.echo "this is a server operating system"
End If
Note: For more information about what returned property values indicate, refer to the MSDN Online WMI reference
Conclusion
Just as there are caveats to everything, scripting comes with the hidden responsibility of not over doing it. Layering too much processing at startup may not be as cumbersome to users as loading things down at logon. Just as user will get frustrated with slow Group Policy processing, they will begin to hate you if your scripts cause them to stare at a screen at logon while it's busy churning away and holding them up from getting to work. Keep your script code tight, clean and minimal. Same goes for Group Policy settings. The old saying is very apropos: Just because you can doesn't mean you should. The secret is balance. Everything comes with a price, but that doesn't mean it's not worth it, as long as you weigh the costs against the benefits.
If you ask most system administrators "how long is too long for a policy to apply or a script to run", you will get a wide range of answers. Both approaches, Group Policy and Scripting, offer simple ways to target your settings to specific users or groups or computers, so you can "ease" them out into production and get user feedback to ensure you mitigate the costs (latency, delay, etc.) against the benefits (configuration management, automation, data collection, etc.). If you're using Group Policy to do your heavy lifting, it may be a good time to at least explore what scripting can do for you. If you're relying on scripting, maybe Group Policy and WMI Filtering is what you should at least look at. And for both, if you have Windows Server 2008 in your environment, maybe it's time to check out Group Policy Preferences as well. With a crappy economy, now is the time to boost your skills and squeeze more value from the tools you have at hand.
If you're storing documents in shares on file servers *and* in Sharepoint (or whatever portal product you have), you have a broken environment.
If you have some computers patched automatically, and others not, you have a broken environment.
If you rely on Automatic Updates, you have a broken environment.
If any of your regular users have local admin rights, you have a broken environment.
If you have IT staff logging on routinely with elevated rights, you have a broken environment.
If your first reaction to accomplishing a new task is *always* to write a script, you have a broken environment.
If it takes you more than an hour to reload a desktop or laptop with a "standard" setup, you have a broken environment.
If you don't have a "standard setup", you have a broken environment.
If you don't have a documented procedure for rebuilding your entire network from a catastrophic failure, you have a broken environment.
If you don't have regular, scheduled backups of system state data for Active Directory domain controllers, as well as every one of your critical member servers, you have a broken environment.
If you haven't tested a complete system/site recovery from backups for your database servers, web servers, domain controllers, and SMS/SCCM/SCOM servers within the past 12 months, you have a broken environment.
If your IT staff walks around the office wearing vendor logo clothing, you have a broken environment.
If one of your IT staff tries to convince management to allow Apple Xserver products into your Windows-based data center, you have a broken environment.
If your critical servers are not properly setup for fault tolerant disks, you have a broken environment.
If your users are saving business critical files on their desktops and laptops, you have a broken environment.
If you're not using at least "some" form of virtualization for at least some of your servers, you have a broken environment.
If your business relies on sharing spreadsheets among more than five users per file on a daily basis, you have a broken environment.
If you can't lay your hands directly on all of your software license docs in one place, at the same time, you have a broken environment.
If more than 1/4 of all your purchased laptops sit on desks overnight, on average for any given night, you have a broken environment.
If your users "lock" or power off their computers every evening, rather than logging off, you have a broken environment.
If you schedule anti-virus and anti-malware scans during normal working hours, you have a broken environment.
If your users aren't "forced" to change their passwords on a controlled interval, you have a broken environment.
If you don't have a detailed plan of what you would do to recover from your data center burning down (literally), you have a broken environment.
If you have more than 4 members in the "Domain Admins" user group (or "Enterprise Admins"), or if you have any permanent members in the "Schema Admins" group, you have a broken environment.
If you discovered more than two issues as a result of reading this cheesy shopping list, you have a broken environment.
Posted on their blog today...
Hi WSUS Admins:
We’ve noticed some confusion about the recently released updates for Microsoft .NET Framework 3.5 SP1. So, let’s see if we can help clarify the differences in the packages. These updates apply to x86 and x64 computers. The detailed update descriptions describe both the platform and OS architecture that apply for each of the updates. You’re also likely wondering about the differences in the update titles. Here are the differences:
1. The update titled “Microsoft .NET framework 3.5 Family Update (KB959209)” updates computers already running .NET Framework 3.5 SP1 with the latest compatibility fixes. So, if you only want to update existing .NET Framework 3.5 SP1 computers with the latest fixes, then approve these packages.
2. The update titled “Microsoft .NET Framework 3.5 Service Pack 1 and .NET Framework 3.5 Family Update (KB951847)” will upgrade computers with .NET Framework 2.0, 3.0, 3.5 to the latest version of the .NET Framework 3.5 SP1, and will also apply KB959209 (#1 above). If you want to upgrade/update all of your computers to the latest version of the .NET Framework and apply the latest compatibility fixes, then approve these packages.
If you know you only need the latest compatibility fixes for 3.5 SP1, then we recommend you only approve the Microsoft .NET framework 3.5 Family Update (KB959209). Otherwise, we recommend that you approve the second update.
Thanks,
The WSUS team
If you're like me, you'll probably just approve both (any/all) and be done with it.
The WSUS Team blog announced today that Service Pack 2 is now available for beta trial participation via the Microsoft Connect web portal here.
In case you're wondering, worried or concerned, WSUS 3.0 SP1 Admin console installs and works just fine on Windows 7. An entry labeled "Windows 7 Client" is available in the Products and Classifications options. If you have installed Windows 7 or plan to use it with WSUS, and you have any dealings with MP3 files, you will definitely want to install update KB 961367 on all of your Win7 clients. So far, I really like Windows 7. I always liked Vista. I get a sick feeling when I have to log into my XP desktop at work. I may get that same feeling having to log into any Vista computers now. Windows 7 is really nice.
This is something you can do for FREE, in a few minutes, to maintain a consistent computer environment. Of course, this is for those of you who cannot or will not use SMS or SCCM or something like that to do the heavy lifting. Windows gives you everything you need to build your own castle of coolness. All you need is some basic scripting knowledge, a little knowledge about Group Policy and basic network sharing permissions stuff.
In a nutshell, create a script, a shared network folder, and a group policy. The Group Policy will configure a "startup script" that is executed each time computers are restarted (as long as their accounts reside in the appropriate OU in Active Directory for where you link the GPO). The script will simply look in a sub-folder for other scripts and run them, if any are found. So you can disable running them by simply moving them to a backup folder at any time. To add a script into the process chain, just drop it into the sub-folder.
When you create the shared folder, make sure you grant the folder NTFS and Share permissions to allow the domain group "Domain Computers" to have Read access. This group is not included in "Everyone", "Users", "Domain Users" or "Authenticated Users", so you have to explicitly apply it. I strongly recommend making the share name hidden by appending a dollar sign ($) to the end to be a little more secure (not a lot, but a little doesn't hurt either). Maybe something like "Server1\ComputerScripts$" or whatever. Within that, create a sub-folder named "RunScripts" or whatever. In the ComputerScripts$ share, create your primary script (in whatever language you prefer, but I recommend something that can be natively run, like BAT/CMD or VBS/JS). This script will simply look in ComputerScripts$\RunScripts for any script files and then execute each one it finds.
NOTE: Startup scripts execute under the local "System" account context, and therefore have local administrative rights to the system. However, the "System" account doesn't have rights to any resources beyond the local computer by default.
NOTE: Because startup scripts are run by the computers, not by users, they cannot access or manipulate most settings or processes which are user-oriented. This is because they execute *before* a user is able to logon.
NOTE: Processes executing as "System" inherit implicit membership in the "Domain Computers" domain security group. This domain group has no default permissions to any resources, nor subsequent membership in any other groups. It exists for you to use IF you decide to use it. Otherwise, it is essentially a dormant resource in the context of a domain environment.
Now, once you have created your shared folder, applied the appropriate permissions, created and linked the GPO to the appropriate OU or container in AD, you are almost ready to go. To test this, drop a simple script into the RunScripts sub-folder that does something like this...
DIR %WINDIR%\SYSTEM32\*.CPL >C:\Applets.txt
As long as your main (primary) script can find and execute this sub-folder script, you should see the "Applets.txt" file created on each computer after it is rebooted. This is a quick way to verify the "system" you have created is working.
Once this is working, you're ready to down a six-pack, crush the cans on your forehead, smack your co-worker in the face and start writing some serious kick-ass scripts to pull things together. I apologize to your co-worker. I shouldn't have suggested you smack him/her. It is the holidays after all.
If you want to take things up a notch, I would suggest considering some more robust tools like KixTart or PowerShell. You don't have to distribute Kix32.exe to every computer as long as they can read and execute it from a network share. If you want to use PowerShell, you may need to deploy the appropriate .NET framework runtime, as well as the PowerShell client components to each computer first. Regardless, this simple, free, basic little system can do wonders for getting a small network of computers whipped into shape and marching in one direction with a little work.
Some pieces of advice:
Don't reinvent the wheel! Whether it's checking to be sure there's not already a GPO setting to accomplish what you need, or if it's writing script code and looking online for existing samples to use. Save time. Laziness is the mother of all automation inventions.
Start small and proceed slowly. Don't rush in and risk making a mess that's hard to troubleshoot.
Create a test OU to link the GPO to. Then gradually move a few computers into it, one at a time. Proceed cautiously for a happier life.
Don't Link your GPO until it's ready. Create it first. Then edit it. Then link it.
Tell at least one joke per day.
Here's an interesting tidbit for you Windows users that also love using BAT files. The FORFILES command. Rather than droll on mindlessly about it, here's the help screen dump for you to enjoy as you sip your favorite holiday drink...
FORFILES [/P pathname] [/M searchmask] [/S] [/C command] [/D [+ | -] {MM/dd/yyyy | dd}]
Description:
Selects a file (or set of files) and executes a command on that file. This is helpful for batch jobs.
Parameter List:
/P pathname Indicates the path to start searching.
The default folder is the current working directory (.).
/M searchmask Searches files according to a searchmask. The default searchmask is '*' .
/S Instructs forfiles to recurse into subdirectories. Like "DIR /S".
/C command Indicates the command to execute for each file.
Command strings should be wrapped in double quotes.
The default command is "cmd /c echo @file".
The following variables can be used in the
command string:
@file - returns the name of the file.
@fname - returns the file name without extension.
@ext - returns only the extension of the file.
@path - returns the full path of the file.
@relpath - returns the relative path of the file.
@isdir - returns "TRUE" if a file type is a directory, and "FALSE" for files.
@fsize - returns the size of the file in bytes.
@fdate - returns the last modified date of the file.
@ftime - returns the last modified time of the file.
To include special characters in the command
line, use the hexadecimal code for the character
in 0xHH format (ex. 0x09 for tab). Internal
CMD.exe commands should be preceded with "cmd /c".
/D date Selects files with a last modified date greater
than or equal to (+), or less than or equal to
(-), the specified date using the
"MM/dd/yyyy" format; or selects files with a
last modified date greater than or equal to (+)
the current date plus "dd" days, or less than or
equal to (-) the current date minus "dd" days. A
valid "dd" number of days can be any number in
the range of 0 - 32768.
"+" is taken as default sign if not specified.
/? Displays this help message.
Examples:
FORFILES /?
FORFILES
FORFILES /P C:\WINDOWS /S /M DNS*.*
FORFILES /S /M *.txt /C "cmd /c type @file | more"
FORFILES /P C:\ /S /M *.bat
FORFILES /D -30 /M *.exe /C "cmd /c echo @path 0x09 was changed 30 days ago"
FORFILES /D 01/01/2001 /C "cmd /c echo @fname is new since Jan 1st 2001"
FORFILES /D +12/26/2008 /C "cmd /c echo @fname is new today"
FORFILES /M *.exe /D +1
FORFILES /S /M *.doc /C "cmd /c echo @fsize"
FORFILES /M *.txt /C "cmd /c if @isdir==FALSE notepad.exe @file"
Happy Holidays!
1. Click Start/Run and type APPWIZ.CPL to open "Add/Remove Programs"
2. Click Start/Run and type SYSDM.CPL to open "System Properties"
3. Click Start/Run and type HDWWIZ.CPL to open the Add New Hardware Wizard
4. Click Start/Run and type NCPA.CPL to open "Network Connections"
5. Click Start/Run and type LOGOFF and press Enter to (guess what?)
1. Automate Disabling/Enabling Your Kids User Accounts
2. Automate Backing Up Your Junk
3. Delete All Files of Type ___ Older Than ___ Days
4. Automate Renaming All Your MP3 Files to a Common Format
5. Forcing Shutdown On Your Kids Computer with a Button Click on a Different Computer
#5 is my favorite. It comes in handy when they give me an attitude. :)
Happy holiday to everyone! Sorry for the late posting, but I've been busy eating and drinking (soft drinks, milk, coffee and juice only). I don't have anything on my plate right now besides not thinking about work and waiting to hear if I'll get to play with Windows 7 in the coming weeks. Besides that, Santa brought us a Wii, so that's keeping us busy.
But while I've got you here reading this, let me know if you know of any programs that can crank out a photo slideshow the same way the AppleTV screensaver does? I really need one for Windows.
http://www.microsoft.com/downloads/details.aspx?familyid=0446cce9-94a4-4fb0-b335-e7516044063d&displaylang=en&tm
System Center Updates Publisher is a stand-alone tool that enables independent software vendors or line-of-business application developers to import software update catalogs, create and modify software update definitions, export update definitions to catalogs, and publish software updates information to a configured update server. By using updates Publisher to define software updates and publish them to the update server, administrators can begin detecting and deploying published updates to client and server computers in their organization.
I might have mentioned a while back that Microsoft occassionally sends out invites to test out "beta exams" at testing centers around the U.S. They might do that outside of the U.S. as well, but I wouldn't know. This time around they were evaluating a new approach to the exam itself. It was indeed very nice, although, since I signed an NDA - that's all I can say about that. The reward was a set of three free exam vouchers, good until June 2009. Very nice and perfect for someone as broke as myself.
Arrrgg! Everytime I hear someone explaining WSUS wrong I gnash my teeth and want to smack them. It's most often not "what" they're saying, but "how" they say it. That usual John Wayne swaggering bravado, eyes half-opened, smug look. 
So, pay attention, please (I absolutely HATE saying "look." or "listen." to start a sentence)...
WSUS is NOT a "push" technology. It does not "push" anything to anyone ever. Not even other WSUS servers. It's not a pusher.
Here's (essentially) how it works:
A WSUS server requests a catalog of updates from either Microsoft's servers, or another WSUS server (aka, an "upstream" server). It posts this catalog to a share and makes it available to clients and downstream WSUS servers to use for assessing which updates they have and do not have. Each client then generates a list of updates it has installed, those that failed to install, those it needs and sends that up to the WSUS server. The WSUS administrator (probably you) reviews the cummulative results and approves or declines updates on the WSUS server via the console interface. Clients will then check back on their assigned schedule to identify updates they need which are approved and available on the WSUS server. The clients "pull" these updates and install them and then report back on the results.
The clients do most of the heavy lifting: They request update catalogs. They audit themselves for missing updates. They report to the WSUS server as to what they have and what they need. They initiate the downloads. They do the installations. They report back their status.
Of course, there are quite a few variations that can exist based on how you configure your WSUS process to work. Clients can automatically do their updates, for example, or they can simply let you know they need updates installed and let you do it manually. There's a lot more granularity, but this is "it" in a nutshell.
Also, another misconception I run across is that WSUS is an "all-or-none" prospect. Meaning that you supposedly cannot divide and conquer your domain computers to have separate configurations and processes. This is totally false. There are many ways to assign different automatic update configuration schemes to groups of computers on your networks. The most common approach is placing computers into distinct OU's within Active Directory based upon their role. For example, desktops in one OU, laptops in another, and servers in yet another OU. This makes it easy to use distinct Group Policy settings for each OU, and hence each role-based group of computers. You can assign different schedules, behaviors, even different WSUS parent servers, to each OU using GPO settings. It's so simple even a caveman can do it. Ooops. Sorry, GEICO, please don't sue me.
So, the next time you're sitting in a IT meeting, and some obnoxious fool across the room starts explaining WSUS as a "push" process, please, please... interrupt them by saying: "Dave says you are a complete idiot and another reason why IT jobs are getting shipped overseas". Then proceed to (politely) describe how WSUS works in the proper manner. You'll be doing the world a favor.
1 - Group Policy is Hype
Hype comes from people. Technology doesn't hype itself. Group Policy is serious stuff. It's not rocket science when you get down to what it's doing and how it works. Sure, there's some intricate processing being done in the background, but in the end, it's simply a way to deploy and manage configuration settings to groups of users or computers. Just as with a box of matches, Group Policy is a tool that can provide enormous benefit and time savings if used properly. Or you can fire it up next to a can of gasoline and burn the house down if you're not careful. It's a powerful tool. Very powerful. So you need to get familiar with it before you unleash it in a production environment. Plan and test in a separate environment - always.
2 - Group Policy will Break Your Network and Clog the Pipes
So will putting a dozen raw potatos down your sink drain at once. If you don't do stupid things you won't get stupid results. Make sure you retain documentation about what your policy settings are doing so that you don't accidentally duplicate the same setting, or worse, push contradictory settings from different policies. Remember to always consider Inheritence, Tatooing and the combined effects of User+Computer settings as they relate to what user and computer accounts are impacted, and where each of them reside within Active Directory. It's all about planning and being careful. Group Policy on it's own will not damage your network. Using it improperly may. It's like driving a car. If you use it improperly you can do bad things. It's not the car's fault. Ok, maybe that was a bad example. It's like using a match (I need to find a better analogy or metaphor).
3 - Group Policy Takes an Expert to Make it Work Properly
Wrong! It takes getting familiar with it. Download and install VMware Player or VIrtual PC or Virtual Box or Parallels or whatever you prefer. Install a virtual guest running Windows Server 2003 or 2008, and another running XP or Vista, and test it out. Get a book and read up. Learn. You have to prepare in order to get a driver's license or pilot's license. You have to prepare in order to build a house. The same applies to using Group Policy. Don't just "figure it out" in production. That's not the way to go.
4 - Group Policy is Great for Deploying Software Installations
For small package on small LAN environments, the answer is "maybe". It depends on how the software is packaged. It also depends on how it installs and how your LAN is built and what sort of throughput limitations or demands are present during the window of time you intend to deploy the package. Much of this holds true for SMS, SCCM, Altiris or anything else as well. To give a few quick examples, you can deploy Adobe Acrobat Reader or WInZip or small applications like these if your network doesn't choke on a lot of traffic happening all at once. I would NOT recommend pushing Office 2007 or Autodesk Inventor 2009 using Group Policy, unless you're planning to quit and make everyone miserable on your last day of work.
5 - Group Policy Still Needs Scripts to Complete the Job
That used to be true. However, with the added capabilities of Group Policy Preferences, you can replace a ton of login scripting with GPP settings now. The ease of use is fantastic. The reliability is superb. The gains are enormous. You can leverage the benefits of GPP features on XP and WS03 as well as WS08 and Vista, as long as you have WS08 servers in your environment to use GPP features.
While third-party products like LikeWise add GPO-like features to Linux clients, I've yet to see anything like Group Policy for OSX or Linux "in general". OpenLDAP is a good solution for network-centric account management, it's doesn't include Group Policy features for managing settings via rules like Active Directory does. The point I'm working towards here is that Group Policy prior to GPP is a huge added benefit over other platform capabilities, which are only possible through extensive scripting (Bash, etc.). Some advanced processing on Windows still requires scripting or application additions, but GPP adds user and computer settings for such things as drive mappings, printer connections, shortcuts, and much more. These things used to require login scripts or startup scripts to accomplish. Not that scripting is entirely unnecessary now, but you have more options at hand to do more with less effort.
Group Policy is without a doubt one of the most powerful and compelling reasons for choosing Microsoft Windows as a business networking platform. It provides built-in, straightforward, centralized management and control over the computers and user settings in your environment. Best of all: It's FREE. And you don't have to download anything to make it work. Enhancements are available, like GPMC, GPP extensions and ADMX templates, etc., but they're not required in order to start using Group Policy right now. As with any tool however, it works best when applied to what it was intended for. Hammers are great for driving nails, but not so great at turning screws.
1 - Windows Server 2008 Doesn't Provide Any Advantages over Windows Server 2003
Wrong! It provides a butt-load of improvements and advantages over WS03. "Butt load" is a certifiable scientific term. I've heard it used by PhD professionals on at least one occassion. Seriously though, if you do a little poking around you can read all the marketing hype mumbo jumbo from Microsoft about how WS08 will make you feel good and evaporate all those pesky event log errors you've been scared to death of trying to figure out. A better suggestion would be to download the trial version and install it inside your favorite virtual machine host and break out your baseball bat to start working on it. "Hands-on" is the best way to learn and evaluate technology. Reading and listening to whiney OSX and Linux nerds won't give you anything remotely close to an accurate picture of WS08. Remember: FUD is your enemy.
2 - Windows Server 2008 is Just an Updated Version of Windows Server 2003
Wrong again! It's nearly a rewrite compared to WS03. It's actually based on Windows Vista. In fact, they share the same code base from Vista SP1 and up. Service Pack 2, which is in public "beta" trials as of this posting, uses one patch file to apply to both Vista and WS08. The only forked versions will be 32-bit, 64-bit, IA64 and multiple language types. It doesn't just look like Vista, it behaves like Vista much moreso than WS03.
3 - To Benefit from Windows Server 2008, You Have to Replace all Other Versions and Run Nothing Else
Nope. You can gain many benefits from the very first member server you drop into production. From virtualiation, to performance improvements, to security improvements, to file and print services improvements to just improved improvements. It's true that some features gain from being in a 100% native environment, mostly with Active Directory, DFSR and things like WS08+Vista SMB file streaming performance improvements, but most features are available without having to go to that much effort. In fact, if you have a mixed environment (I'm talking about operating systems, not sexual preferences here), you will gain from added UNIX interoperability improvements as well. There's a butt-load of information about new features and improvements up on TechNet also.
4 - There are Too Many Products That Don't Work With Windows Server 2008
I've heard this said but can't seem to find any concrete examples from anyone saying it. It's always "I've heard that ____" blah blah blah. I do know there are some versions of products that won't work reliably on WS08, but in every case I've seen thus far, there is a newer version available from those vendors to address WS08 compatability. Even my crappy old UPS appliance software written for XP/2003 works just fine on WS08 with a free hotfix. And since anything written to work with Vista will work with WS08, you can even run WS08 on your desktop or laptop and install the desktop experience feature to add all the CPU-draining coolness you enjoy in Vista. It actually makes a great desktop and a fantastic Christmas or Hannukah gift. I can never spell Hanukah properly.
5 - Windows Server 2008 Will Destroy the World
Only if you're entire world is built on the premise that WS08 is bad. Once you take off the goggles, and put down the crack pipe, and give it a real hands-on evaluation, you will see that it's actually rock solid. What will destory your world is spending too much time tinkering with computers. You need to get out and do something outdoors once in a while. Shovel snow. Water a garden. Walk around the block. Find an Apple or Linux fan and challenge them to a cage match and invite your neighbors to watch. It's all about the entertainment.
As far a "myths" go, I say the same thing to anyone that is dealing with FUD from their peers: Check it out for yourself. Regardless of whether it's a Microsoft product or not. Never form your opinions on hear-say information. It will always cause problems for you down the road. With so many vendors, including Microsoft, providing easy access to free evaluation downloads, there's no reason to not test drive things yourself. And with so many FREE virtualization products, like VMware Player, Virtual PC, VirtualBox and so on, it's a no-brainer. Go ahead, you have some holiday time coming up. After you've opened your presents and drank all your beer or Scotch or eggnog, stagger down to your PC dungeon and fire some goodies up and expand your brain. Consider it a gift to yourself. My gift suggestion to you is Windows Server 2008. Happy Holidays! :)
This article popped up on my RSS feed and looks pretty interesting. One of those "Doh!" moments. You know, when you read it and think "I would have known to avoid that scenario", but we are all prone to running into things like this during one of our semi-awake moments (Mondays). The first question in my head when I read it was why would someone have both and SCCM SUP role *AND* a WSUS server operating independently in the same production environment (read: AD domain)? I'm sure someone could think of a reason or situation where that would be necessary, but I can't think of any where I couldn't come up with another reason to NOT do that. By the way, I totally agree with the 2nd option the author puts forth (which he prefers). FWIW.
Remember when SUS came out and the list of things it could manage was just a wee little baby? Crawling around and leaving stains on the rug everywhere. Then came WUS and it learned to walk and you had to start moving things up higher and higher and higher from the floor. The cabinet locks were used. The gates were up. Baby was growing up. Then came WSUS 3 and suddenly Junior was practicing how to shave. WSUS 3.0 SP1 now has a 5 O'clock shadow, a shaving kit in the drawer, a bottle of half-emptied Scotch on the sink counter and bunch of people passed out naked all over the apartment.
Ok. I'm getting off the path here a bit. Sorry. Posted less often means I build up stupid things that have to come out from time to time.
So, what does the products list in WSUS 3.0 SP1 look like now? Well, as of today, here's what my synchronization list looks like. I won't waste any time making fun of the stupid names, but I would like to see Microsoft form a group to study the idea of standardized product names and making them a bit shorter.
BizTalk Server
Host Integration Server 2000
Host Integration Server 2004
Host Integration Server 2006
Compute Cluster Pack
Compute Cluster Pack
Exchange
Exchange 2000 Server
Exchange Server 2003
Exchange Server 2007 anti-spam
Exchange Server 2007
Expression
Expression Media 2
Expression Media V1
Forefront
Forefront Client Security
Forefront code named Stirling Beta version
Forefront Threat Management Gateway, Definition Updates for HTTP Malware Inspection
Forefront TMG MBE
Internet Security and Acceleration Server
Firewall Client for ISA Server
Internet Security and Acceleration Server 2004
Internet Security and Acceleration Server 2006
Microsoft Codename Max
Max
Microsoft Core XML Services
Microsoft System Center Data Protection Manager
Data Protection Manager 2006
Network Monitor
Network Monitor 3
Office Communications Server And Office Communicator
Office Communications Server 2007
Office
Office 2002/XP
Office 2003
Office 2007
SDK Components
CAPICOM
Silverlight
Silverlight
SQL Server
SQL Server 2005
SQL Server Feature Pack
SQL Server
System Center Online
Category for System Center Online Client
System Center Virtual Machine Manager
System Center Virtual Machine Manager 2007
Systems Management Server
System Center Configuration Management 2007
Systems Management Server 2003
Virtual Server
Virtual PC
Virtual Server
Visual Studio
Visual Studio 2005
Visual Studio 2008
Windows Essential Business Server
Windows Essential Business Server 2008
Windows Essential Business Server Preinstallation Tools
Windows Live
Mail Installation and Upgrades
OneCare Family Safety Installation
Photo Gallery Installation and Upgrades
Sign-In Assistant Installation and Upgrades
Toolbar Installation and Upgrades
Windows Live Toolbar
Windows Live
Writer Installation and Upgrades
Windows Small Business Server
Windows Small Business Server 2003
Windows
Windows 2000
Windows 7 Client
Windows Defender
Windows Internet Explorer 7 Dynamic Installer
Windows Internet Explorer 8 Dynamic Installer
Windows Media Dynamic Installer
Windows Server 2003, Datacenter Edition
Windows Server 2003
Windows Server 2008 Server Manager - Windows Server Update Services
Windows Server 2008 Server Manager Dynamic Installer
Windows Server 2008
Windows Ultimate Extras
Windows Vista Dynamic Installer
Windows Vista Ultimate Language Packs
Windows Vista
Windows XP 64-Bit Edition Version 2003
Windows Xp x64 Edition
Windows XP
Works
Microsoft Works 8
Zune
Zune Software
Junior is growing so fast.
Confused by the title? No problem. Most of my titles are confusing, even to me, and I write them. I've often said that Microsoft has led the way on making platform plumbing that works. Sure, there's no shortage of platform API's for Linux, UNIX, wenix, theynix, henix, shenix and even OSX. But nobody has laid the foundations like Microsoft has. WMI/WBEM, ADSI, the registry, COM, .NET, and one of the unsung heroes of plumbing: The event log system.
When I mentioned Lego Blocks in the title, it should have started to make sense near the end of the first paragraph. But that's essentially "it" really. Microsoft has made the operating system, and indeed most of their applications and services, into building blocks that we as consumers or developers can assemble into our own little constructs to solve our unique needs. Better yet, they give you two options in most cases: Off-the-shelf, or build-your-own. The off-the-shelf stuff consists of System Center mostly, but it goes beyond that. I've seen people build their own identity and account management systems, but Microsoft also has ILM. So no matter what you prefer, they have it pretty much covered. Perfect? No. Nice? Absolutely.
Case in point: Monitoring Event Logs in a WAN environment.
So, you have some irritating SOX auditor sniveling down your neck about why you're not collecting and analyzing event logs from all your 10,000,000 servers in production. You look around and think "I know, I'll implement SCOM and then beat that sniveling turd over the head with the box when I'm ton!" But then the finance guy reminds you that due to economic "constraints" there is no budget. Most of your infrastructure improvement/optimization plans are going to be pushed back to 2010 unless your department gets its own stimulus package ahead of schedule. Fear not. It can still be done, and for next-to-zero cost. I don't say "free" because nothing is really "free", but there's no need to buy anything more than you already have. Well, that is IF you have either Windows Server 2008 and Vista machines -OR- the Windows WS-Management system installed on Windows Server 2003 or XP.
Rather than try to one-up another how-to for setting this up, I'll point you to one of the best tutorials I've seen yet. Simple. Straightforward. To the point.
That article will at first appear to be more complicated than it really is. Once you read through it and actually do it once, you'll realize how easy it is to make this work in your environment. Just keep in mind the footnotes throughout. Especially the ones that describe dealing with hierarchy and using WECUTIL. I was going to write my own how-to on this very same topic until I ran across that article and, well, nevermind. I'm not bummed out. I'm actually glad someone did it already and did such a great job on it.
Taking this a step further, you will soon see how flexible the Task Scheduler is within Vista and WS08 and how you can fire all sorts of tasks based upon a desired event occurring. You can fire scripts that open database connections and write entries into tables, or send e-mail messages or shut things down or disable accounts for people you don't like (just kidding, but I know that it's very easy to do. heh heh). So, essentially, you can build your own SCOM-ish solution with nothing more than what comes in Windows (or available as a free download) and a little time. Pretty cool. Is this as far as you can go? Not at all! You could keep going and push the envelope as far as you want. You could build a system that automatically performs corrective action tasks based upon detecting events. Or finds incorrect settings and runs scripts to correct them. Or shuts down a system that begins doing bad things. The possibilities are endless.
I've searched for something parallel to this capability on Linux and OSX but you end up piecing things together on your own a LOT more. A HECK OF A LOT MORE. As in, you will be compiling things in many cases. Or you will be scouring web sites for shareware and retail products to fill the void. This is what I mean by how nice it is that Microsoft gives us a free Lego building block kit with every Windows installation. And they give you the glue to put things together (Vbscript, JScript, BAT/CMD, COM API's, .NET, etc.) Yes, I know that Lego's don't need glue, but just go with it.
Some have wondered where I've been (virtually speaking). Most of my time is now consumed with commuting and family chores while at home. I still blog mindlessly about more benign issues when I can, on my other blog. After I was riffed from my systems engineering job, I ended up going back to work for a former employer doing software packaging and customer support. Most of my work involves Wise script editing and digging through various vendor nightmares for accomplishing silent mass deployments (kind of funny, but when I was much younger, that's how I used to refer to farting). I suppose you could say some packages are silent but deadly, heh heh, er um, well, nevermind.
Given that I don't work with server products on a daily basis, it's not first and foremost on my mind to blog about these days. I miss it sometimes. Then again, I don't miss the after hours calls, which often go along with supporting "infrastructure". I never supported Exchange however, which as far as I've seen is a good thing. Some of the most called upon folks I know are Exchange admins. They get called late at night, on weekends and holidays. Whenever a CEO can't get his e-mail while sitting in the airport, he's going to call his IT victims to get it working ASAP. Nobody cares about software packaging folks. Less pay but less pressure also.
Almost as tortured are the systems management folks. While they're not usually on call after hours as often as email staff, they do spend a huge amount of time preparing for mass deployments or following up on them when things get weird. The packaging phase, testing phase, piloting phase, staging and deployment phase, status monitoring and troubleshooting. Then repeating the process for each product and upgrade. This doesn't even include the time eaten up for monthly software patches either. Then there's the custom reports everyone has to have. And the (thankfully infrequent) changes to inventory settings. Then just when you catch a breath, something goes red in the status logs and you break out the lab coats and microscopes to track down the cause. If that leads to a hotfix or service pack, then there's even more work to do preparing for that and making it happen.
I suppose what should be the take away here is how little known such efforts are outside of the narrow worlds these people work within. Most managers outside of IT have no clue how much time and effort that consumes to keep the machinery running smoothly. They think that as long as e-mail flows and pages come out of the printers, that IT people just sit around and goof off.
I digress.
Anyhow, I've been laying low. Just making sure I get my work done and trying to do my best. With the economy going down the toilet, we all have to do our best to ensure we have something to count on. I'm hitting the bed now to get up at 5 a.m. and do my usual drive to get to work by 6 a.m.
If I don't drop another post here before long, I would like to wish everyone a happy and safe holiday season and best of fortune in the coming year.
I think I've installed SMS 2003 at least twenty times or more in lab environments, and quite a few in production environments. I've installed SCCM in at least a dozen lab environments but not in production (so far). But it's been a few months and things get rusty. I thought I'd drop SCCM into my home network and play around with it (things geeky nerds do when we get bored and have a few minutes to burn). But I started doubting my memory and some of the minutae regarding orders of things and so forth. I remember the pieces, but some of the steps had me wondering if my memory was failing me. I'm 44 so in IT terms I'm a relic. I should grow a beard and start smoking a pipe I suppose. Then the younger geeks might think I was like a professor or something. Ugly thought. Nevermind.
So, I decided to get a refresher to help jog my thoughts into the proper order and save time and headache. Books, web sites, blogs, whitepapers, PDF guides, hmmm. Which to choose. I then realized that one of the best resources was right in front of my nose: Level 5 IT Guides. The guide I was looking for is Brian Tucker's System Center Configuration Manager series, and I have to say it was perfect. Not only is it thorough, but it is "to the point" and doesn't waste time. After all, he doesn't have any other agenda like selling products or services for SCCM. He just focuses on getting the job done and walking through the steps carefully and clearly. Great job and much appreciated!
This was posted on the Server Core blog today and seems interesting enough to share here as well...
Now that a build of Windows Server 2008 R2 has been released, I can start talking about what we have been working on. In a Windows Server 2008 R2 Server Core installation we have:
· Active Directory Certificate Services is now an available Server Role.
· WoW64 support for 32bit applications is now an optional feature in Server Core and is not installed by default. This enables you to further reduce the footprint of Server Core if you remove it from the image. I’m interested in hearing feedback on our decision to not install this by default – is this a good idea, or will you always need to install this because you have 32bit code you need to run?
· Added the following as optional features:
-
Subset of .NET Framework 2.0
-
Subset of .NET Framework 3.0 and 3.5 – WCF, WF, and LINQ
-
Windows PowerShell
-
ASP.NET and additional IIS support – the only IIS feature not available in Server Core is the management GUI
-
FSRM
The important thing to note about all of the above is that they are all optional so if you won’t be using them you don’t need to install, manage, and maintain them.
In later posts I’ll get into more details on how to install these, what I mean by subsets of .NET, as well as other topics.
Andrew
It's amazing that announcements of exploits for Vista are "news" when you consider that they seemed like a daily occurrence for XP. So now there's another FUD spinner going on to freak out everyone about using Vista. Ooooh, Vista... If you install it, your house will burn down. Markets will crash. Earthquakes will destroy entire cities. People will starve. Pa-leeeez.
Just patch it and shut up. Oh, and if you have any common sense at all, you'll avoid opening stupid "greeting card" emails, Nigerian credit scams, and PayPal account verification notices, not to mention steering clear of Warez and Porn sites. If you stick to things that are safe you're probably going to be safe as well. It's like life in general. If you drive your Lexus into the wrong part of town at the wrong time of day (night), you're probably increasing your chances of something bad happening to you.
Dave's equation once again: WSUS + Using-WSUS = less crap to deal with
More Posts
Next page »