The RunBook will perform the following steps:

• Prompt you for necessary information to begin
• Create the user account in AD
• Create the home directory on the fileserver and set NTFS security
• Create the users exchange mailbox on a specific exchange server and/or mailbox store, acording to user’s last name. This is usefull if you want to spread a large number of users over an array of exchange boxes
• Setup the AD account with additional properties such as phone numbers, website and initial password. Password will be set according to a template you can edit. In my example I’ve configured it to be the users Lastname + the last two digits of the data of birth.
• Send the user an initial welcome email which may include an attachments.

The buildingblock will prompt for a whole bunch of stuff, like the OU path in which to create the users in etc. This should only happen once and will help adapt the BB to your lab environment.

You might ask; “So what’s the big deal with creating this as a runbook and not as a project or module?” Essentially for a lab environment you’re spot on. If you’ve got your DC, Fileserver, Exchange etc. on one box, you could very well do with merely a module. However, in the real world you are likely to have these things on different boxes, i.e. you need some way of tying the whole thing together so some tasks happens on one agent, while another tasks is executed elsewhere. That’s why we use Wisdom Runbooks.

Again, remember – this and and all other buildingblocks were just put together to demonstrate a concept. They do not come with any guarantee expressed or implied that they’ll work in environment, so test them in a lab/sandbox first, to make sure they do what you expect.

Click on the Rar here to download the buildingblock: 

Anyway, have fun with it. If you have questions to the BB, feel free to drop a comment in the forums

/Max

In order to do this, you need to have the proper credentials for the PowerFuse datastore.

The article available here, will show you how to deal with this problem. A nifty buildingblock for Wisdom has also been included in the article.

Great work chaps, thanks for sharing!

Click here to see the postings and download the Buildingblocks

We have some users which share a mandatory profile, where the default webpage for IE has been set to about:blank or something else long ago. This setting coded into the .man profile and we don’t want to bother hacking into it since our goal would be to have it changed dynamically, according to group membership.

For example: We want to have users in group1 initially having www.batman.com as their homepage and group2 should have www.superman.com as their homepage. To make the entire thing a bit more interesting, we want to provide the user with the option to change their homepage to something else if they prefer to do so.

To summarize we are talking about creating a dynamic, group assigned voulentary user registry setting on top of a mandatory profile. Sounds iffy? Not at all. This example is easy to follow, but you can of course just download the PowerFuse buildingblock at the end of the article. The registry key we use for this example is HKCUSoftwareMicrosoftInternet ExplorerMainStart Page (REG_SZ)

1. If you haven’t already done so, create a PowerFuse application for Internet Explorer (other browsers can be used, but you’ll have to figure out the registrysettings then for yourself)
2. Edit the IE app and go to the Configuration | PowerLaunch tab, click Add.
3. Create a powerlaunch user registry setting for the IE startup page www.batman.com. using the HKCU registry path above. Make sure to mark the reghack with the Run-Once checkmark.
4. Go to the Access Control tab of the reghack, assign it to group1.
5. Export the newly created reghack to a temporary file. This done in the “Registry|Export registry file…” menu inside the PowerFuse registry buffer editor. We are going to use this export one steap further ahead.
6. Save the reghack and return to the PowerLaunch tab of the application
7. Repeat step 2 above, then go to the Registry|Import registry file… and pull the temporary regfile in again (it can safely be deleted after this btw).  In the new reghack, change the startup page to www.superman.com and assign this one to group2. Notice that the name and any comments you added before was preserved in the regfile. Once you’ve configured the reghacks for both groups it should look like this:
8. Let’s setup the User Preferences. Go to Properties|User Preferences, while still editing the app. Here we can specify one or more seperate items which should be saved before the logoff destroys the mandatory profle. Using the Add button, you can choose to add:
   1. A single registry value (like we are using here)
   2. A registry key (containing multiple values)
   3. A registry tree (a branch containing multiple registry keys)
   4. A single file in the profile (such as normal.dot for office)
   5. A folder in the profile (such as cookies or favorites)
9. Fashion the user preference so it looks something like this (remember, you can download the buildingblock below if you want to make sure you build it right). Click on the image to zoom.

When the app has been saved and the user sessions refreshed, PowerFuse will write the correct IE startup page to the registry uppon first time user launch of IE. During the session, the user may perhaps change the homepage of IE to something completely different. Regardless of this, User Preferences will capture the current value of the IE startpage key at logoff and save it, just before the mandatory profile is tossed into Mount Doom. To try all this out for yourself, download the BuildingBlock:

Rightclick and save-target-as here:

 PowerFuse BuildingBlock: Default Global authorizations. This buildingblock will help you get from pilot to production much faster, by implementing some best practices for authorizations. The buildingblock contains a set of Global Authorized files which will enable the most common authorisations for Windows XP and VMware workstation. This will enable you to switch both Application Security and Read-Only Blanketing into Blocking mode much faster. For those of you out there using Vista, a seperate buildingblock will be made available later, as there are loads more stuff that Vista wants to pull up at logon. Besides, XP/2003 administrators will probably be happy not having to weed out a ton of unnecessary authorizations. If you want to have a look what’s in the box :), check out this nifty PowerFuse Instant-Report:  

 PowerFuse BuildingBlock: Best Practice Registry settings. This is another buildingblock which will help you speed up initial deployment by implementing some of the most common HKCU registry settings. These cover a lot of common stuff, best practices, etc. For example you can redirect shell folders, disable the XP tour, configure the explorer windows properly and much more. You can preview the contens of the buildingblock by having a look at an Instant-Report for the module here:  

  Wisdom BuildingBlock: Add a computer to the domain. This is a simple module, however it ought to be in the toolbox of every Wisdom admin out there. It simply enters a computer into a domain, but also modifies the DefaultDomain registry key, so the user logging on afterwards does not have to change the domain dropdown. Believe it or not, this is a frequent item which helpdesks have to deal with, so why not eliminate it all together? The module should need no editing at all. When you import it into your Wisdom 2009 environment, it will prompt you for all necessary information.

  Wisdom BuildingBlock: Super Security Audit (21MB). With this module you will quickly get an overview of any outstanding security issues, related to missing updates, vunerabilities etc. The module installs MBSA 2.1 + the security cab files and report everything back to the Wisdom console. Also the module will report you MS product keys and do a WGA check on the machines you schedule the job on. There are several cool things worth mentioning about this module.

• The module contains all the components ready to go. No extra downloads are necessary.
• Just download, import and execute.
• It can operate offline, which makes it great for those kinds of datacenters where allowing the servers to access the Internet is not an option
• The module supports execution on both 32 and 64 bit OS’s. Wisdom will make sure the right bit-version of MBSA is executed on the righ platform

If you would like a sneak-peak of what this module can do look here:

This article explains how to both cure that situation if things have gone megabad, but also how to prevent it from happening in the future. 

Click here to read the full article.

This may at first sound like utter nonsense, but think of it like this: Let’s say that you want to enable users to have the same profile across different systems, say Vista, XP and Terminal Services 2003. Impossible you say? Nope, this can be done.  There is a nifty whitepaper from RES, available here which describes the entire procedure:  

To sum up the whitepaper, you can:

• Create a mandatory profile for each of the operating systems which require it
• Upload these profiles to PowerFuse Custom Resources, which will automagically replicate them out locally to the %programfiles%\res powerfuse\data\dbcache \resources\customresources folder on all machines running PowerFuse. Make a structure in PowerFuse Custom Ressources as seen here on the right (note you do not have to create all the folders etc. just point to the root folder of an existing mandatory profile and the RES console will import it with all subdirectories)
• Run the module on all target machines where users will be logging in.
• Configure User Preferences to grab the stuff which you want to store for the users uppon logout.
• Modify the User records in AD, change the user profile path of the users to the variable, say %manprofile% (remember, this can be done in Wisdom too! – perhaps a subject for another buildingblock)

This result is quite spectacular:  All users share one singular profile path (which is dynamic).  The user session will be loading the right mandator profile, as it will be specified by the variable. The path will be local, resulting in zero network traffic as result of loading the profile locally.

The Wisdom module has been designed with module parameters, so you can customize your own paths etc, making it quite easy to use.

Click here to download the module: 

Click the rarfile here to download it: 

This file contains two buildingblocks which contains some nice registry fixes picked up along the way, which can make things somewhat easier for you.  The Reghacks in these buildingblocks is just collections of relevant stuff that’s been googled over time. Slice and dice the modules as you like. The Workstation building block contains the following Reghacks

• Delete cached copies of roaming profiles. We all know what  this one does, right?
• Disable the XP tour. Eliminates that pesky bubble which will bother new users the first 3 times they logon
• Remove VMware HGFS.dat (shared folder support) This thing has a nasty habbit of locking up profiles. Note: The HGFS reghack is disabled per default as you probably will need to change the Network Provider order so it matches your target environment
• Remove USB device checking. This removes the This Device Can Perform Faster message. This is a legacy setting back from VMware 5x as it didn’t support USB 2.0. You may however still find use for it
• Kill the indexing service on Vista. If you know where your s*** is, all this thing is gonna do is slow you down.
• Clean up StubPaths. This will remove the first-time config of IE, Outlook Express etc at first login. You’re probably going to use PowerFuse for this anyway, right?
• Reduce animation on .default profile. This can reduce the zoom effect when the PowerFuse loader screen pops up (not tested completely) but give it a whirl

The Server Best Practices module contains:

• Disable the Shutdown Event Tracker. Yeah yeah, lot’s of good reasons to keep it, but if you hate to answer why you want to reboot your server, this is for you.
• Disable print spooler logging stuff to the eventlog
• Disable the Manage Your Server thing from popping up the first time you log in
• Delete the HKLM shadow keys (see the module for more info)
• Clean out specific citrix stuff from the HKLM Run key, such as Java update and the Icabar.
• Clean up the stub paths, same as the workstation module.

On a side note, RESguru.com now has two new co-authors!

/TRG