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.
To get a list of DC’s and dump it to a text file, type cscript enumcomputers.js /dc > dclist.txt
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
Open dctasklist.txt in Notepad, any word processor or even Microsoft Excel.
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:
Open \Windows\ADAM\ADAM-ADSIEDIT.msc on the existing ISA Config Storage server.
Navigate to CN=Configuration, CN=Sites, CN=Default-First-Site-Name,CN=Servers.
Delete the server on which you have the installation problem.
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:
Open ADSIEDIT
Find the user for whom you want to restrict the view and open the properties
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:
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!
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:
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:
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 -andbetween the two parameters. Similarly, change all equal signs (=) to -eq.
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.
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.
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:
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.
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.
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.