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

部落格


3月1日

Windows Live Writer

 

This is really cool.

Windows Live writer is a free tool from Microsoft that lets you post entries to your blog without having to log in to your blog provider website. It works more like Microsoft Word, with spell check as you type, easy formatting, and very easy insertion of pictures and tables. You can also put these cool drop shadows on your images!

 

image

If you're a blogger, give it a shot. It is also available with the latest version of Windows Live Messenger. Works with Google Blogger too!

GMail user data exposed in Kuwait

 

Talk about security - and Google.

GMail users in Kuwait and some other countries reporting being able to read other GMail users' email without having to log in.

Full Story:
http://www.news.com/8301-10784_3-9875714-7.html

Google claims that an 'ISP caching problem' that allowed users to log in to other users' mailboxes. This talks volumes about Google's security, doesn't it? Does this mean that an ISP can break Gmail security if it really wants? Wait a minute - how can 'caching' at the ISP preserve Gmail sessions? Some neat security, huh?

No wonder Gmail is still in Beta.

2月21日

To the Core: Windows Server 2008 in production!



After a week of preparation, I put a DHCP server running on Server Core in production last night! Server Core is Windows Server 2008's non-GUI installation mode.

I am told by Microsoft that we are one of the first to put the Windows Server 2008 Server Core RTM code into production and that they are proud of me. I'm inspired!

As for the DHCP server, it's working merrily now, giving away IP addresses to anything that has a NIC and needs an IP - on two of our Active directory sites. I will soon be publishing an article on this topic.

My next Windows Server 2008 plaything would be NAP. It's amazing how the new Server Core architecture runs on so less resources, at the same time improving performance and security.
2月19日

Did you know

... that a Microsoft Product Key never contains a the letters I, O and the numbers 0 (zero) and 1 (one). This is probably done to prevent users from getting confused!

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.