個人檔案Technically Speaking部落格清單SkyDrive 工具 說明

部落格


2月17日

Articles on enabling Remote Desktop

It's been some time since I've written new articles on shijaz.com :)

I have added two new articles on Remote Desktop:

Getting a list of scheduled tasks on all servers

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.
2月15日

Windows Server 2008 by Lee

Microsoft conducted a presentation on Windows Server 2008 for business decision makers, IT staff, faculty and students at Higher Colleges of Technology. The event was held on 14th February, 2007 at Abu Dhabi Men's College.

Desmond Lee presented an interesting view of Windows Server 2008, with live demos and shared some exciting information about the new features. Through his humorous, yet effective, mode of presentation he was an instant hit with the students :-)


2月14日

Heroes Happen {here}: Launch event


Windows Server 2008, SQL Server 2008 and Visual Studio 2008 are launching in the Middle East on the following dates:

10th March - Abu Dhabi
12th March - Kuwait
17th March - Bahrain
19th March - Doha
23rd March - Oman
27th March - Dubai

Mark your calendars and join the excitement. Microsoft is giving away RTM evaluation copies of these products at the events. Click here to register.

Launching in Abu Dhabi on 10th March 2008 at the Intercontinental. See you there.
2月12日

Microsoft Responds to Yahoo! Announcement

Microsoft Corporation (NASDAQ:MSFT) issued the following statement on February 11 in response to the announcement by Yahoo! Inc. (NASDAQ:YHOO) that its Board of Directors has rejected Microsoft’s previously announced proposal to acquire Yahoo!:

It is unfortunate that Yahoo! has not embraced our full and fair proposal to combine our companies. Based on conversations with stakeholders of both companies, we are confident that moving forward promptly to consummate a transaction is in the best interests of all parties.

We are offering shareholders superior value and the opportunity to participate in the upside of the combined company. The combination also offers an increasingly exciting set of solutions for consumers, publishers and advertisers while becoming better positioned to compete in the online services market.

A Microsoft-Yahoo! combination will create a more effective company that would provide greater value and service to our customers. Furthermore, the combination will create a more competitive marketplace by establishing a compelling number two competitor for Internet search and online advertising.

The Yahoo! response does not change our belief in the strategic and financial merits of our proposal. As we have said previously, Microsoft reserves the right to pursue all necessary steps to ensure that Yahoo!’s shareholders are provided with the opportunity to realize the value inherent in our proposal.


On February 1, 2008, Microsoft announced a proposal to acquire all the outstanding shares of Yahoo! common stock for per share consideration of $31 representing a total equity value of approximately $44.6 billion and a 62 percent premium above the closing price of Yahoo! common stock based on the closing prices of the stocks of both companies on Jan. 31, 2008, the last day of trading prior to Microsoft’s announcement. Microsoft’s proposal would allow the Yahoo! shareholders to elect to receive cash or a fixed number of shares of Microsoft common stock, with the total consideration payable to Yahoo! shareholders consisting of one-half cash and one-half Microsoft common stock. [Read more]
2月7日

Heroes Happen here: Comics from Microsoft

Microsoft and Seagate have launched a blog-style comics page, Heroes Happen Here, with one comic being released each day. The comics are IT-related. You can subscribe to it by RSS for your daily share of IT humour.

2月5日

"Setup failed to install ADAM in replica mode"

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.


1月31日

How to specify the default Address List in OWA

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.

My first computer

I just came across an article on TechRepublic titled "Dinosaur sightings: The Commodore 64". This one was of special interest to me - just because the Commodore 64 is the first computer that I ever laid my hands on!

Check out the specifications on the box (64 KB RAM, wow):


And here's how it looked. The two smaller white things are modems. I didn't have one of those on my Commodore 64.


We used to hook it up to the family TV because it didn't have a monitor. We didn't have a hard drive either - in those days hard drives on computers were strictly optional! We used to store our stuff on 5.25" floppy disks of 720K capacity.

This post on TechRepublic brought out a lot of old memories.

1月29日

How to bulk edit an Active Directory attribute

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

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.

Upgrading recipient policies created in Exchange 2003

After installing Exchange Server 2007 Mailbox server into an Exchange Server 2003 organization, you open Exchange Management Console and navigate to Organization Configuration > Hub Transport > Email Address Policies.

You find all the legacy recipient policies that you created in Exchange 2003 over here, but when you try to edit a recipient policy, you get 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.

So just how do you fix your email address policy? Yup, you will need to use Exchange Management Shell, no matter how much you hate it.

First, lets fix the Default policy using the Set-EmailAddressPolicy cmdlet:

Set-EmailAddressPolicy "Default Policy" -IncludedRecipients AllRecipients

Hit 'Y' when you are asked to confirm the upgrade.
If you have additional recipient policies, you need to upgrade them as required. One important thing to remember is that, in Exchange 2007, you can specify only from the following 'filter' fields, as far as email address policies (recipient policies) are concerned:
  • Department
  • Company
  • CustomAttribute1, CustomAttribute2, ... , CustomAttribute15
In Exchange 2003, it was possible to define recipient policies from complex LDAP queries, but I see that kind of flexibility is unavailable in Exchange Server 2007. For instance, in Exchange Server 2003, you could create a recipient policy for all users who have mailboxes in a particular mailbox store.

Anyways, lets upgrade our policy using one of the available tactics - lets say - based on Department. If I have an Exchange 2003 recipient policy that gives all users from the sales department email addresses of the form @sales.mydomain.com, my Set-EmailAddressPolicy command would look like this:

Set-EmailAddressPolicy "Sales Dept Recipient Policy" -ConditionalDepartment 'Sales' -IncludedRecipients AllRecipients

Note that I do not need to specify the email address format for upgrading the recipient policy.
1月28日

When Setup fails: Exchange Server 2007 Mailbox Server Role

I went ahead to install the mailbox server role on one of the brand new servers commissioned for Exchange Server 2007.

The prerequisite checks went OK, and setup began doing the 'real stuff'. Happiness was shortlived, because, towards the end setup showed that it failed. The following error was thrown:

An unexpected error has occurred and a Watson dump is being generated: The Exchange server address list service failed to respond. This could be because of an address list or email address policy configuration error. It was running command '$error.Clear(); $count=0; $ExchangeServers = Get-ExchangeServer -DomainController $RoleDomainController; foreach($server in $ExchangeServers) { if(($server.AdminDisplayVersion.Build -gt 641) -and ($server.IsMailboxServer -eq $true)) { $count++; } } if( $count -eq 1) { Set-OrganizationConfig -DomainController $RoleDomainController; }'.

I closed the Setup program, and tried to assess what's been done. I could see that Exchange Management Console and Exchange Management Shell have been installed and that I could open both, but I could not edit the existing address lists or recipient policies from Exchange Management Console.

Upon further investigation, it dawned on me that Exchange Server 2007 does not use LDAP filters for recipient policies! It uses OPATH instead. How to make this change from LDAP to OPATH filters will be discussed in another post, but in order to make this change I need setup to complete successfully, otherwise I get an error that the Address List service is not responding. Now we have a deadlock situation.

We can trick Exchange 2007 setup into believing that the filter is alright by removing parenthesis "(", ")"and ampersand "&" symbols from the filter. To do this,
  • Open ADSIEDIT
  • Navigate to CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=, CN=Recipient Policies
  • You will find all your Exchange 2000/2003 recipient policies here. Open each and find the purportedSearch attribute. Click Edit to open the value. Note the original value of this field and save it in a notepad file. Then hit the Clear button to change the value to (not set).
  • Do the previous step for each recipient policy
  • Re-run Setup. You will find that setup completes successfully!

The next question is, what do I do with the original values of purportedSearch? I put them back as they were before setup, so that I can upgrade the policies to Exchange 2007 later without disturbing the current Exchange 2003 users.

1月27日

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

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.

1月24日

Internet Explorer 7 to be distributed via WSUS on February 12

On February 12, 2008 Microsoft will release the Windows Internet Explorer 7 Installation and Availability update to Windows Server Update Services (WSUS). IE 7.0 will be distributed as an Update Rollup package.

The update is an installation package that will completely upgrade Windows machines running IE 6.0 to IE 7.0.

If you have configured WSUS to "auto-approve" Update Rollup packages, IE 7 will be automatically approved for installation after February 12, 2008 and consequently, you may want to take the actions below to manage how and when this update is installed. You will need to take action if:
  • You use WSUS 3.0 to manage updates in your organization.
  • You have Windows XP Service Pack 2 (SP2)-based computers or Windows Server 2003 Service Pack 1 (SP1)-based computers that have Internet Explorer 6 installed.
  • You do not want to upgrade Internet Explorer 6 machines to Windows Internet Explorer 7 at this time.
  • You have configured WSUS to auto-approve Update Rollups for installation.

See the Microsoft KB article for more information.

Bill Gates' last day at Microsoft

 

 

 


This is a humorous video of Bill Gates' last day at Microsoft shown during Microsoft CES 2008. Starring Bill Gates, Brian Williams, Steve Ballmer, Matthew McConaughey, Robbie Bach, Jay-Z, Bono, Steven Spielberg, George Clooney, Jon Stewart, Kevin Turner, Hillary Clinton, Barack Obama, Al Gore, Ray Ozzie and Craig Mundie.

1月23日

AutoRuns from SysInternals


AutoRuns is a Microsoft SysInternals utility that lets you take a deep-down look at what lurks under the hood when your computer/server starts. You can use Autoruns to identify programs that automatically start when your computer starts and you can disable them by unchecking the box.

This is especially useful when you are trying to boost the startup performance for your system, or even if you're trying to locate some kind of unidentified malware or a spy program. Autoruns categorizes the images into various tabs like logon, IE plugins, Drivers, Winsock providers, etc to help you easily find what you're looking for. The new version also has a tab that displays the Windows Vista gadgets that are loaded at startup.



I think it's really an awesome tool. You can download Autoruns from the Microsoft SysInternals website.
1月20日

Exchange Server 2007: Problems during PrepareAD

I was all set last Thursday to upgrade my Active Directory schema for my Exchange Server 2007 implementation. I opted to use the GUI for installing one of the servers. If all prerequisites are met, the GUI installation normally upgrades the schema and prepares the domain for Exchange Server 2007.

I ran into a glitch during the preparation process. I got the following error, and the preparation failed:

CN=All Groups,CN=All Address Lists,CN=Address Lists Container,CN=,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=, DC= The object already exists.

To take a closer look, I ran setup.com from the command line using the /PrepareSchema switch and it was successful. No problem there. Next, I proceeded with the /PrepareAD switch.
This is where the above error message surfaced.

I opened up ADSIEDIT and found the above object in the Configuration partition. The All Groups object is an Exchange 2003 view that lists out all the distribution groups in your organization in the GAL. Probably there was some change done to the object which Exchange 2007 Setup did not understand. So, in order to let Exchange 2007 create its own "All Groups" object, I renamed the existing object to "All Groups1".

The organization preparation process now completed without a glitch, and it created its own "All Groups" container.

Of course, this will result in two "All Groups" showing up in the GAL in Outlook, so you might want to delete the older one eventually.


A word of caution here - this post, like all my other posts does not carry any endorsement from Microsoft. This happened to work well for me, and is my based on my belief and understanding of the implications.

Windows Vista always logs you on with a temporary profile?

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!
1月9日

Opening blocked attachments in Outlook

Some file extensions are blocked by Microsoft Outlook for the potential damage that they may cause. File types blocked include EXE, COM, MDB and many others.

Outlook displays a message that it has blocked the attachment:


Sometimes it becomes necessary to "unblock" a particular file extension. One of the most common requests is to unblock Access database files (*.mdb). Let's see how this can be done:
  1. On the desktop running Outlook, open Registry Editor.
  2. Navigate to HKEY_CURRENT_USER\Software\Microsoft\Office\xx.x \Outlook\Security where xx.x is your Outlook version number (9.0, 10.0, or 11.0)
  3. Add a new string named Level1Remove
  4. Add value to this string with all the extensions that you want to unblock, separated by a semicolon. (For example: .mdb;.url ) Remember to put the dot before the extension.

It should, however, be kept in mind that unblocking a particular file type introduces new risk, as the user can also receive a malicious file of the same type from another user or the internet and he/she might inadvertently open it.

For Outlook 2007, you need to insert the string in the following key HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\12.0\Outlook\Security. If the key path doesn't exist, you can create it.