Skip to content

Creating custom MMC consoles

I was going to write an article about authoring your own MMC consoles and I may still do that, however the main reason why I would want to create my own MMC console and lock it down is if I were delegating certain tasks to a junior administrator (like user management in Active Directory).

It turns out that Daniel Petri has already written an excellent article which shows how an administrator can create a “Taskpad” which is essentially a custom MMC console which is locked down to a set of specific administrative tasks. This taskpad can then be used by a junior administrator on a day to day basis as an alternative to granting him direct access to Active Directory for a certain domain.

This is also useful when you want an office manager or a department head to keep the AD attributes of an OU he is responsible for up to date with contact/company information, such as title, manager, phone numbers, etc.

Daniel’s article can be found here: Create Taskpads for Active Directory Operations

 

Make sure to look around on Daniel’s site, as it contains a plethora of other useful information.

When the PCL driver doesn’t work try the Postscript driver

Postscript vs. PCL1 is not something I’d like to discuss on this blog, however I will admit that there are instances when the PCL drivers won’t get the job done, specially with PDF files (granted, a PDF file is essentially a postscript file, but that’s a discussion for another day).

On more than one occasion I have come up across a few files some Excel, some PDF that for whatever reason won’t print flawlessly when spooled to a printer that is using a PCL driver on the print server but when I create another printer on the print server using the Postscript driver the file prints out without a problem. The issue may occur to a local printer but I have only seen it with higher yield printers like the HP Color LaserJet 4700n connected to a print server through the network.

The bottom line is that it is worth a try to use the Postscript driver for those problematic files that just don’t print correctly when using the PCL driver (read the article linked on note 1 below for some of the Postscript pros which may provide some understanding into why the Postscript driver prints a document with more fidelity than PCL).

Also, I think it should be noted that due to the nature of Windows printing, it is perfectly acceptable to have two printers each using a different set of drivers on the system, all you need to do is have them use the same port but a different driver and naturally have a different name so that you can tell them apart and there is no naming conflicts when creating the second printer.

 

Notes
1. http://www.laserquipt.com/support/idx/0/063/article/PCL-vs-Postscript.html

Infrastructure Master FSMO role and Global Catalogs in your Active Directory domain

Remember: If only some of your Domain Controllers are Global Catalogs make sure that the domain controller that holds your Infrastructure FSMO role1 is not a Global Catalog. The reason for this is that a global catalog that holds the infrastructure master role will stop looking for and removing phantom objects in your directory since it will have no phantom objects (we all know global catalogs hold partial information on every object in the directory) because it knows about every object in the directory if even a little.

However, if all your domain controllers are global catalogs, then it doesn’t matter where the infrastructure master lies since all domain controllers will know about everything in the directory and will (unless there are bigger problems) have accurate information about your directory objects.

 

Notes
1. http://support.microsoft.com/kb/197132

About mailbox searching in Outlook 2003/2007 [with Exchange]

A quick tip for anyone who is experiencing issues searching their mailbox on Outlook 2003 (with or without Windows Search) and Outlook 2007 (preferably with Windows Search enabled on non-Vista/7 machines). If the mailbox mode is in Online mode, that is, it is not in Cached Exchange Mode, you might want/have to enable Cached Exchange Mode for Outlook 2003 in order for your searches to work properly.

Now I have found that for Outlook 2007 search to work (though I have to admit, I have only verified these findings when Windows Search was installed), you need to also enable Cached Exchange Mode. I can only guess that the reasoning behind this is that the indexer can index your mailbox locally and thus provide you with the search results you need (in a fast responsive manner) when your mailbox is stored on your hard drive as an OST file. Now (and this is only speculation since I haven’t bothered to look this up) it is very possible that if the Exchange Server is being indexed and you are running Exchange 2007 and Windows Server 2008 or Windows Search on Windows Server 2003 and Windows Search on your workstation that Outlook 2007 will provide you with search results without having to enable Cached Exchange Mode by passing the search request to the indexer on the server running Microsoft Exchange, similar to how Windows Search retrieves file search results across the network.

However, the whole point of this post is that it is worth a try enabling Cached Exchange Mode if you have a search related issue on an Outlook client that connects to an Exchange Server and everything else you’ve tried isn’t working, like rebuilding the index, or reinstalling Windows Search, etc.

Make use of additional UPN suffixes for your Active Directory domain

With the advent of Active Directory, the old school Security Accounts Manager (SAM) account names are almost a thing of the past, not that anyone got the memo. Most people still authenticate to their domain using their SAM account name, which is usually DOMAIN\username; with DOMAIN being the NETBIOS name for the AD domain.

While this is still (as previously mentioned) widely used and acceptable, in my opinion there is a more appealing method for having users log into their accounts on Active Directory networks, and that is using the User Principal Name (or UPN) suffix. A UPN will allow a user to specify their username@upnsuffix to log into their account, and you can now see why this is appealing for some users. If your domain name does not live in the global DNS namespace, you probably have an Active Directory domain utilizing a .local suffix, or a sub-domain of a domain that does live in the global DNS namespace like corp.mydomain.com. By default, the UPN that is added (and thus shows up in the Account tab of an Active Directory user’s properties) is the fully qualified domain name (FQDN) of your Active Directory domain. This can be quite a task to type, if, for instance your FQDN is corp.mydomain.com. In my opinion this is one of the main reasons that a down-level SAM account name is still used to log into AD domains most of the time today. But what if you could add the UPN suffix of your internet facing domain name, the domain name that your users are assigned for their e-mail addresses to the list of UPN suffixes that they can use to log into the network?

As an administrator, you will know that each user will at least remember their e-mail address, so they can share it with co-workers or colleagues outside the company (and the GAL). Allowing a user to log on with their e-mail address gives your users less to remember and in the end can even save you a support call if they need to log in to OWA or Outlook on their laptop configured with Outlook Anywhere. The reason for this is that they are logging into their domain and will sooner remember to type in their e-mail address than remember the NETBIOS name of the domain they use to log into the corporate network.

Now to answer your question before you ask it, you can add any UPN suffix you want inside your Active Directory forest, you will naturally want to choose something your users can relate to, but you don’t necessarily need to follow that advice either. Once you add a UPN suffix to your forest, you simply need to navigate to the Account tab on a user’s properties in AD and change the drop down in the User logon name: section to the UPN suffix that you’ve just added to the forest. You will recognize the UPN suffix because it looks like the end of an e-mail address. This can also be scripted using the DS commands (more on those in later posts), in case you want to change the UPN suffixes for accounts already present in Active Directory to allow log on with your newly created UPN suffix.

So now, I’m sure you are asking yourself “Where is it that I add these UPN suffixes? Tell me already!”

You can add a UPN suffix to your forest by opening the Active Directory Domains and Trusts snap-in, right clicking the root of the snap-in which is Active Directory Domains and Trusts and clicking on Properties. From there you will see a UPN Suffixes tab, and it is here where you can add the new UPN suffix to be used in your forest (and domains within the forest).

If you only have one domain controller (shame on you, there should be at least two DCs in each AD domain), but if you do only have the one, you should be able to make the change instantaneously to your accounts. Otherwise, you will need to either force replication using the repadmin utility, or wait long enough for the DCs to replicate between each other.

Now your users will be able to log into the domain using username@mycompany.com instead of username@corp.mycompany.com or username@mycompany.local or MYCOMPANY\username, and you want this because a user will sooner remember his e-mail address than any of the latter example account names. However, just because they can log in with one does not mean they can’t log in with the others, as long as the UPN suffixes are there and/or the NETBIOS name is correct, the user should be able to log into the network using any of the previous account names. Correction: Once the UPN suffix for an account has been set, the user will only be able to authenticate using that UPN suffix, the domain NETBIOS name followed by a backslash and the username will also continue to work (since that will provide the server with the old SAM account name).

Remember to use the Synthetic SCSI Controller in your Hyper-V VMs

A few minutes ago I was going over the Server 2008 Performance Tuning Guidelines1 and one of the recommendations for the Hyper-V role caught my eye, it was something I’d previously read before, but for whatever reason wasn’t currently implementing in my infrastructure: The Synthetic SCSI Controller.

The synthetic SCSI storage controller performs better over the emulated IDE controller, and while Hyper-V requires an IDE controller be present in a virtual machine for booting the VM, Microsoft recommends that an administrator mount any other VHDs with a high expected I/O rate to the synthetic SCSI controller mainly because of reduced CPU overhead, causing better performance. This is because the SCSI controller has a direct link to the VMBus, which gives it a performance advantage over the emulated IDE controller.

Another related recommendation is to mount a server’s paging file, and any log and database files to their own separate synthetic controller, and preferably keep these VHD files on their own set of physical disks, in order to minimize the risk of your disks becoming a bottleneck that can affect overall performance.

Notes
1. http://www.microsoft.com/whdc/system/sysperf/Perf_tun_srv.mspx

A tip for working with accounts on Windows 7 Home Premium

I have two HTPCs at home, one in my bedroom and one in my living room (*cough*, the living room HTPC is coming soon), as well as another notebook that my lady uses. These machines are a perfect candidate for the Windows 7 family pack that Microsoft is offering for $150, which is good news for me as far as licensing goes.

Since these machines will are simply for entertainment purposes, and web browsing, they don’t need any features other than the ones offered by Home Premium, unfortunately, the RDP host is not available for Home Premium, so I will likely end up using VNC (though I have seen that Windows 7 and VNC aren’t the best of buddies yet), LogMeIn or another remote control technology for management, but we will see, in the meantime I have my rubber keyboard and small USB mouse handy for plugging into the front USB ports on my HTPCs and using my TV as a monitor. But I digress, while the HTPCs will be auto logging into their accounts and starting up XBMC on boot, that leaves me with the third PC in the house that has a local admin account, as well as a service account granting it access to media files on my workstation. Since my workstation is domain joined, it can join a HomeGroup, it cannot serve files to a HomeGroup (for security purposes I assume), so I am stuck using a service account. This leaves me with an extra account showing up in my Welcome screen (and the welcome screen of the other machine) that I do not care to see, so I set out looking for a way to hide the service account.

The following registry hack (place usual registry editing warning here), will get the job done, and as an added bonus, I have also included the name of the user account applet for those of us that dislike the new user account control panel fluff.

Without further ado, the registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList

Inside this registry key, create a new DWORD value with the account name to hide, leave the DWORD with a value of 0.

Log off or reboot and voila, the account should no longer appear in the Welcome screen, but you should still be able to authenticate to the machine using this account. This is useful in scenarios where you cannot have a HomeGroup, or choose not to use a HomeGroup and would like to share resources between machines using good old fashioned service accounts without having the account name lingering in the Welcome screen.

Also, as promised, from the Run dialog, typing netplwiz will bring up the old school user accounts applet, this is very useful in the case of Windows 7 Home Premium, since there is no Local Users & Groups applet in “Computer Management” as in Windows 7 Professional and above.

Give it a try!

Work with files using PowerShell

Quick reminder to myself, since this can easily be looked up online, the following code snippets are useful for mass renaming files in a directory, for instance when renaming a series of TV Show episodes into a format that TV Rename can recognize and subsequently rename with correct episode title information for use in XBMC.

By the way, these code snippets were spread out to multiple lines for ease of reading, but PowerShell doesn’t care about them and when I write them into the console myself, they are all in a single line.

   1: $count=1; 

   2: foreach ($f in gci) 

   3: { 

   4:     $s = "S01E{0:0#}" -f $count; 

   5:     $count++; 

   6:     $s2 = "{0}{1}" -f $s, $f.extension; 

   7:     ren $f -newname $s2 

   8: }

While I am pretty sure that the above code can be made much more inline than what I have made it, or more elegant, for a beginner with PowerShell (who still has a book on PowerShell to read) like myself, this is sufficient, again, not sure how efficient it is, but I know it can be made better. What this particular snippet does is, keep a counter, and rename each file it finds with a number that sequentially increments by 1, yielding: S01E01.avi, S01E02.avi, S01E03.avi. You will notice that the file is renamed while retaining the extension of the original file, so if the files are .mpg or .jpg, the extension will not change with the new filename.

 

This next snippet, is useful if you have a few files that you can want to convert to AVI (or any other format that FFmpeg supports converting to) all the files in a directory, this was useful when I had a few WMV files that I needed to convert to AVI so that I could then use HandBrake to convert to MP4s that I could view on my iPhone.

(This snippet requires the .basename property to be registered/added to the FileInfo object: http://blogs.msdn.com/powershell/archive/2006/06/24/645981.aspx has details)

   1: foreach ($f in gci) 

   2: { 

   3:     if ($f.extension -eq ".wmv") 

   4:     {

   5:          .\ffmpeg -i $f.name -b 900 -vcodec libx264 -f avi -threads 6 "$($f.basename).avi" 

   6:     }

   7: }

In essence, this snippet queries all the files in the directory, if their extension is .WMV the files are then passed through an ffmpeg command which will convert the files to an H.264 encoded AVI file, keeping the audio stream the same. It is stuff like this that makes scripting (and PowerShell in particular) so interesting and useful, it saves you the time and repetition of certain tasks and allows you to set them overnight and wake up to them having completed in the morning.

 

This concludes my first post, I will be posting some more in the future, mainly for my own self reference, but I am sure that if I need to remember something, someone else might be interested in these little bits of information that I am storing away, at the very least I know where I am filing them away so that I can get rid of the sticky notes that they occupy on my desktop!