Getting a list of scheduled tasks on all servers

by Shijaz Abdulla on 17.02.2008 at 11:26

There is a great script on Windows IT Pro that helps you get a list of all workstations/servers/domain controllers in a domain and then list the Scheduled Tasks that have been configured on these machines.

The script, written by Bill Stewart, can be downloaded from the Windows IT Pro website.

Essentially, this is how it can be put to use:

  1. To get a list of DC’s and dump it to a text file, type cscript enumcomputers.js /dc > dclist.txt
  2. Next, feed this list of DC’s to enumtasks.cmd and ask it to dump a list of scheduled tasks for each DC to another text file: enumtasks dclist.txt >dctasklist.txt
  3. Open dctasklist.txt in Notepad, any word processor or even Microsoft Excel.


"Setup failed to install ADAM in replica mode"

by Shijaz Abdulla on 05.02.2008 at 08:14

If you have already have ISA Server 2006 Enterprise Edition installed and you are trying to installing ISA Server on another server and configuring it as a replica of the Configuration store, you may get the following error on Windows Server 2003 R2:

“Setup failed to install ADAM in replica mode.”

Setup then exits and you are unable to complete the installation. This usually happens if there was a previous failed installation from the machine that you’re trying to join to the array. You will need to cleanup the values related to the server you’re installing from the ADAM installed on your first configuration store, which stores config information for the array.

A simple solution to this is to ensure that both nodes are running Windows Server 2003 R2 and then edit the ADAM to remove the orphaned server on which installation is failing:

  1. Open \Windows\ADAM\ADAM-ADSIEDIT.msc on the existing ISA Config Storage server.
  2. Navigate to CN=Configuration, CN=Sites, CN=Default-First-Site-Name,CN=Servers.
  3. Delete the server on which you have the installation problem.

Re-run the installation, it should succeed now.


How to specify the default Address List in OWA

by Shijaz Abdulla on 31.01.2008 at 17:56

By default, Microsoft Outlook Web Access shows all address lists in Active Directory, regardless of the permissions that are set on the address list. To restrict access so that users can only view the address lists that are contained in their own OU, you can configure the msExchQueryBaseDN attribute for the OWA user.

In an Active Directory environment with a large number of users where there is a need to filter the long list to just a number of relevant recipients, this is particularly useful.

Here’s how to go about it:

  1. Open ADSIEDIT
  2. Find the user for whom you want to restrict the view and open the properties
  3. Find the msExchQueryBaseDN attribute. Enter the DN for the OU or restricted Address list you want the user to see in OWA. To enable user to see all lists, just clear the field.

To find the DN for the restricted address list you created, open ADSIEDIT and navigate to Configuration > Services > Microsoft Exchange > [Organization Name] > Address Lists container. Here is an example:

CN=My Address List,CN=All Address Lists,CN=Address Lists Container,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=MyDomain,DC=com

If you prefer to use the DN of an OU, it would look something like this:

OU=Department,OU=Division,DC=MyDomain,DC=com

If you want to edit msExchQueryBaseDN attribute for a large number of users (entire OU or domain), you can use the ADModify tool.


How to bulk edit an Active Directory attribute

by Shijaz Abdulla on 29.01.2008 at 18:08

Everybody knows that if you want to manually edit the value for an attribute in Active Directory, you ought to be using ADSIEDIT.

But what if you just realized that you have to modify a particular attribute for a large number of Active Directory users, if not all users? Would this mean opening up each user object in ADSIEDIT and modifying the required attribute?

Thankfully, there is the ADModify tool from Microsoft PSS that lets you bulk-edit Active directory. You simply set the filter on what users should be affected, and then specify the attribute that needs to be changed and the value to which it should be changed. You can even make the values to by typing the word null as the value.


A word of caution here – Bulk edits can be really, really painful if you do it wrong. You can seriously mess up your Active Directory if you’re not careful!


Upgrading address lists created in Exchange Server 2003

by Shijaz Abdulla on 29.01.2008 at 16:22

EHLO again.

Hope you enjoyed my previous post that explains how to upgrade Exchange 2003 recipient policies for use with Exchange Server 2007.

This post deals with the “art and science” of upgrading Exchange 2003 Address Lists to its Exchange Server 2007 form. I say “art and science” because it can be a little tricky to understand for those who havent worked much on Powershell or any scripting/coding environment.

If you click on an address list created by Exchange 2003 in the Exchange Management Console, you will receive the following error:

Unable to edit the specified E-mail address policy. E-mail address policies created with legacy versions of exchange must be upgraded using the ‘Set-EmailAddressPolicy’ task, with the Exchange 2007 Recipient Filter specified. specified.

Exchange 2003 Address Lists have a recipient filter that is made up of an LDAP filter. Exchange Server 2007, on the other hand, understands only OPATH filters. The trick is to convert the LDAP filter to an OPATH filter, and this needs to be done manually.

I’m going to explain this with the help of an example. Lets open an Address List in Exchange 2003 System Manager and examine the LDAP filter:

(& (& (& (mailnickname=*) ( (& (objectCategory=person) (objectClass=user) (homeMDB=CN=Mega MailStore (EXCH01),CN=SG01,CN=InformationStore,CN=EXCH01,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=mydomain,DC=com) ) ) ) ))

To refresh our brains, this LDAP filter basically creates an Address list out of all users that have a mailbox in the ‘Mega MailStore’ mailbox store on EXCH01 server.

Before we convert this LDAP to OPATH, lets write this in a better way:

(&
(&
(&
(mailnickname=*)
( (&
(objectCategory=person)
(objectClass=user)
(homeMDB=CN=Mega MailStore (EXCH01),CN=SG01,CN=InformationStore,CN=EXCH01,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=mydomain,DC=com)
) )
)
)
)

Now, carefully change all ampersands (&) to an -and. The ampersands are placed in a prefix fashion in LDAP filter, but in OPATH, its much simpler – you place -and between the two parameters. Similarly, change all equal signs (=) to -eq.

(RecipientType -eq ‘UserMailbox’)
-and
(Database -eq ‘CN=Mega MailStore (EXCH01),CN=SG01,CN=InformationStore,CN=EXCH01,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=mydomain,DC=com’)

Notice that I have also replaced the property ‘homeMDB’ with ‘Database’. This kind of change is required to convert LDAP property names to OPATH. You can get a complete list of properties here.

So, I arrive at my full command:

Set-AddressList “Mega users” -RecipientFilter { (RecipientType -eq ‘UserMailbox’) -and (Database -eq ‘CN=Mega MailStore (EXCH01),CN=SG01,CN=InformationStore,CN=EXCH01,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=mydomain,DC=com’) }

The guys at Microsoft Exchange Team have more to say about conversion from LDAP to OPATH, and is worth a peek.


A few things to check in AD before moving to Exchange 2007

by Shijaz Abdulla on 27.01.2008 at 12:19

Here are a few things to check in your Active Directory before you co-exist Exchange Server 2007 in a Exchange Server 2003 environment.

  • For all your Exchange users and groups, make sure Exchange mailbox alias field does not contain spaces or characters other than a to z (uppercase or lowercase), digits from 0 to 9, !, #, $, %, &, ‘, *, +, -, /, =, ?, ^, _, `, {, , } or ~. One or more periods may be embedded in an alias, but each one of them should be preceded and followed by at least one of the other characters. The @ symbol is not allowed in an alias.
  • For all your Exchange users, make sure the UserPrincipalName (aka Logon name) is “user@domain.com” and not just “user”. I have seent that this problem is usually found on users that are created in Active Directory by Cisco Unity.
  • Make sure your display names do not contain leading or trailing white spaces, i.e. the first and last characters in a display name cannot be a white space.

Usually these kind of problems are found in large environments where user provisioning is automated by a third party application or script. If any of the above conditions apply, Exchange Management Console (or get-recipient shell command) will warn you of inconsistent Active Directory objects.


Windows Vista always logs you on with a temporary profile?

by Shijaz Abdulla on 20.01.2008 at 08:33

If you’re facing problems logging in with your domain account to Windows Vista computer joined to a domain, and you’re wondering why you’re always getting logged on with a “temporary profile” on your Windows Vista computer, you need to read this post.

You’ve tried it all, deleting and recreating the profile, deleting the C:\users\%username% folder, etc. But the problem still remains.

This is because your domain user account is a member of either the Guests or Domain Guests local user group in the Windows Vista computer. Remove yourself from the group and feel the magic! :)

If that doesn’t work, here is another tip:

Open up Registry Editor, navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

You will find one entry for each profile. Check the following for the user account in question:

  1. Ensure the key name doesn’t end in “.bad
  2. Ensure the RefCount value is 0
  3. Ensure the State value is 0

Thanks goes to my colleague Georgee for this tip!


How to disable the warning message in Windows Vista Remote Desktop Connection

by Shijaz Abdulla on 31.12.2007 at 10:18
When you connect to a machine running Windows 2000 or Windows Server 2003 from Windows Vista RDP, you may have noticed the following warning:

“Remote Desktop cannot verify the identity of the computer you want to connect to.”

This is good, but it’s rather annoying to be notified each time you want to connect to a server! To turn off the warning,
- Open the Remote Desktop Connection application and click Options.
- On the Advanced tab, select the option Always connect, even if authentication fails.


How to make out a Windows 3.1 veteran

by Shijaz Abdulla on 24.12.2007 at 12:40

You can always tell a Windows 3.1 user by the way he closes a window, even in Windows Vista. A Windows 3.1 user almost always closes a window by double-clicking on the left of the window. That’s because, back in the times of Windows 3.1, there was no close button on the right of the window.

Take a look at the left of a window in Windows 3.1:


The box with the big dash is called the control box and clicking on it will yield a menu showing options to minimize, maximize and close. Double-clicking on the control box closes the window! And that’s where it all began.

A user can activate the menu by pressing Alt+Spacebar. Why? Because the big dash on the control box is actually a representation of the spacebar. The MDI child window also has a control box, but with a smaller dash. So, how do we activate this menu? Yup, you guessed right – Alt+Hyphen!

It is rather interesting to note that the ‘double-click-on-the-left-to-close’ functionality is still available in Windows Vista, and probably forever in every release of Windows. The Alt+Spacebar and the Alt+Hyphen features are still available too, even though the control boxes don’t bear the dashes anymore. As for me, yes, I do close windows from the left at times. Ahem.


A handy tip for Vista dual monitor users

by Shijaz Abdulla on 14.12.2007 at 12:48




You like Windows Vista gadgets, but you feel that it clutters up your desktop, leaving lesser space for your desktop icons. You like to have the sidebar always on top, but at the same time you don’t want to reduce the screen area of your applications.

If you’re using dual monitors on Windows Vista, here’s a handy tip: You can use your secondary screen for the gadgets!


Why did I do this?

Well, this leaves more room on my primary (read: more important) monitor. My applications are free to roam the entire canvas and I always get the bigger picture. On my second monitor all the gadgets, the clock, the to-do notes, and everything is within easy view at anytime. If you’re an administrator, you can use the secondary monitor for Remote Desktop connections to servers. You can even use the Remote Desktop gadget to save time.

How did I do this?

  • Go to Control Panel\Appearance and Personalization\Personalization. Open Display Settings.
  • Click on your second monitor and check the box “Extend the desktop onto this monitor“.

  • Go to Control Panel\Appearance and Personalization. Open Windows Sidebar properties.
  • Under “Display Sidebar on monitor“, choose the second monitor.





Next posts >