Modify User Password Settings and Account Expiration Date

Description:
Script that performs three functions for all the users in organizational unit:
1) Ensures that all passwords will expire;
2) Requires users to change their password;
3) Assigns an expiration date to the user account.

Language: VBScript
Script Code

Const ADS_UF_DONT_EXPIRE_PASSWD = &h10000
set colItems = GetObject ("LDAP://ou=put_your_OU, dc=put_your_domaint, dc=com")

colItems.Filter = Array("user")
For Each objUser in colItems
'--Remove Non-Expiring Password
intUAC = objUser.Get("userAccountControl")

If ADS_UF_DONT_EXPIRE_PASSWD AND intUAC Then
objUser.Put "userAccountControl", intUAC XOR ADS_UF_DONT_EXPIRE_PASSWD
objUser.SetInfo
End If
'--Require Users to Change Their Password
objUser.Put "pwdLastSet", 0
objUser.SetInfo

'-- Put Expiration Date to user account
objUser.AccountExpirationDate = "07/30/2007"
objUser.SetInfo
Next

Script In Microsoft Site

Understanding Exchange Databases Disk Consumption

Exchange databases need disk space, once they run out of disk space they can not continue to function. My aim in this article is not to describe methods of preventing or solving the disk space problem(even though I will provide a tip or two)- my aim is to describe and explain the way that Exchange databases uses disk space.

As a direct evolutionary phase that stems from my first article the subject I would like to address in my second article is again disk space consumption but this time by the Exchange databases.

What will you gain from this you ask?

The answer is simple - a better understanding of how databases consume disk space which will enable you to manage the disk space you control in a more efficient manner.

Uncovering the databases

Exchange databases are based on the JET engine, actually a variant of the JET engine called Extensible Storage Engine (ESE). ESE is a multi-user database that supports full Data Manipulation Language (DML) and Data Definition Language(DDL). ESE is optimized for fast retrieval of data since this is the main function that the database performs.

Examining the versions of the ESE engines used by the different versions of Exchange server will uncover the fact that there is a difference between Exchange 5.5 and Exchange 2000/2003.

Exchange 5.5 uses a version of the ESE called ESE97 while Exchange 2000/2003 uses a version called ESE98. Now this may seem a subtle difference but it's not.

To understand the differences just take a look at the database file types in the different versions…

EDB files

The rich-text database (EDB) is the database type we are used to seeing in pre-2000 Exchange servers. The EDB database may also be called the MAPI database since it hosts all information submitted by the MAPI client(Outlook). The data itself is stored in a proprietary format called Microsoft Database Encapsulated Format (MDBEF).

It is worthwhile to mention that all messages (whether they are MAPI messages, SMTP or HTTP messages) have some of their properties saved in the rich-text database.

STM files

The native content database (STM) or the streaming database holds messages that were submitted by non-MAPI clients (post Exchange 5.5). The file is called a streaming file since data is added to it sequentially in its native format. The data itself inside the STM file is not encoded or encrypted in any way so if a store is dismounted the file can be viewed using a text editor.

Dealing with the files

The process of understanding how disk space is consumed by Exchange 5.5 databases is more straightforward since there is only one file type that consumes disk space. Exchange 2000/2003 on the other hand is a bit more complex since it uses two types of files for each "store". 

Nevertheless, when looking at disk space consumption the two files in use by Exchange 2000/2003 (EDB & STM) should be regarded as one entity- the store.

Dissecting disk space usage

To understand disk space consumption by Exchange databases follow figure 1 and the description for each section.

Fig 1: Description of disk space

1. Hard Drive/Disk Space – The information is saved on –you guessed it - a hard drive!!! Any unused space on the hard drive can be used for the databases/store.
2. Database/Store – The database is the placeholder for the information. The database files grow by 2MB increments. To prevent excessive fragmentation of the database on the hard drive you can change the increments to 16MB. This change can be done by using ADSIEDIT and accessing a specific storage group through the Configuration partition of the Active Directory. On the storage groups properties edit the msExchESEParamDbExtensionSize parameter and set it to 4096.
3. Data- This part of the database is the actual data that users will access and update.
4. Recoverable Items - Restoring a specific item on an Exchange server can be quite a pain (even though using a Recovery Storage Group makes it a lot easier). To help system administrators deal with this problem each store can retain items for a specific time (specified by the administrator). Items that are past their retention time (and under specific circumstances backed-up) will be tombstoned and removed from the database/store.
5. Recyclable Space - Space that is free and can be reused by new messages. Keep in mind that this space may be fragmented and spread inside the database. In figure 1 the space is at the end of the database since the database has undergone online maintenance.

Show me the numbers

Checking the space used by the database itself is quite straightforward - use any tool such as the Windows Explorer to check the database file size and/or the free space on the disk.

To be on top of things Exchange administrators should always know the size of the different parts of their Exchange databases.

Measuring Recyclable Space

Measuring the recyclable space can be done by either searching for event 1221 in the Application log or by using ESEUTIL to provide the information.

Event 1221 provides a conservative estimate of recyclable space in the database. If the database will be defragmented (offline) then you will gain at least the space specified in the event.

Currently there is some controversy around the question of event 1221 including both the EDB and the STM file for Exchange 2000/2003. It seems that this event only includes the EDB file.

Fig 2: Event 1221 on Exchange 5.5

To receive a more accurate estimate of the white space the ESEUTIL tool can be used. Invoking the ‘ESEUTIL.EXE /MS [database.edb] command on an unmounted store will provide you with a more accurate estimate on the recyclable space found in the store. The output of the command is similar to the following one:

The first part of the output called “SLV SPACE DUMP” provides information about the STM file. By multiplying the value of “Free:” with 4096 bytes you will receive the size of the recyclable space in the STM file.

The second part of the output called “SPACE DUMP” provides information about the EDB file. By multiplying the number at the bottom of the “Available” column with 4096 bytes you will receive the size of the recyclable space in the EDB file.

Measuring the size and quantity of recoverable items

When you are pressed for disk space you will use any and all items at your disposal to gain disk space -this may include jettisoning the Recoverable Items. To measure the size of the recoverable items you can use Performance Monitor. The specific counter you use is called: “Total Size of Recoverable Items”.

Fig 3: Monitoring the size of recoverable items.

If you need to jettison the items you can lower the retention time on the store and configure the online maintenance process to occur - this is not recommended unless you are really pressed for space.

Contemplating

When you understand a system you become one with the system-------- really!!! :)

On a more serious note a better understanding of the system will help you be a better system administrator so I hope that I helped you with this journey…

 

• Author: Erik Rozman

 

 

Windows Vista no longer includes support for the ActiveX control that is used for HTML editing in Outlook Web Access

On a computer that is running Microsoft Windows Vista, you cannot perform any editing tasks that you typically expect to perform. For example, you cannot perform the following tasks:
•Compose a new e-mail message
•Reply to an e-mail message
•Create a new contact, task, note, journal entry, or appointment
•Change any configuration in the Outlook Web Access options folderAdditionally, you may receive an error message when you try to perform these tasks.

RESOLUTION

This Microsoft Exchange Server hotfix http://www.microsoft.com/downloads/details.aspx?FamilyId=5BC06E8A-08EB-4976-BC68-A03EBE3A2552&displaylang=en resolves this issue. This hotfix enables a new editor for Internet Explorer. The new editor uses an Internet Explorer "iframe" instead of an ActiveX control. After you apply hotfix 911829, you are not required to first click in the compose frame in Outlook Web Access before you edit text.

Important
For this resolution to work, you must apply the hotfix to both the front-end server and to the back-end server.

All about Defrag the exchange database

Eseutil /D Defragmentation Mode

Eseutil's /D switch can be used to defragment and compact a database offline. The defragmentation option makes used storage contiguous, eliminates unused storage, and compacts the database thereby reducing the database's size.
Eseutil's /D switch can be used to defragment and compact a database. During typical operations, database files never shrink below their current size. As space in the database is freed by deletion of items, existing pages are reused where possible. Typically, a Microsoft® Exchange Server database will grow for several months after it is put in service, but eventually the database size stabilizes.
Under typical conditions, performing an offline defragmentation will not permanently recover significant disk space. The file will usually grow again to its previous un-defragmented size. Special circumstances, such as moving many mailboxes out of the database, may make it worthwhile to defragment the database offline. By default, during typical operation, the database is logically defragmented nightly. This does not reduce the size of the file on disk, but does make the database perform efficiently.
Note:
You can use the Eseutil utility to defragment the information store and directory in Microsoft Exchange Server 5.5 and to defragment the information store in Microsoft Exchange 2000 and newer versions.

How Does Eseutil Defrag Work?
When Eseutil defragments a database by eliminating unused storage and compacting the database, Eseutil actually creates a new database that contains all the information from the original database. When defragmentation is complete, the original database is deleted or saved to a user-specified location, and the new version is copied over the original. If the utility encounters a serious logical problem in the database, defragmentation stops. The database must then first be repaired with Eseutil /P before it can be defragmented.
When an offline defragmentation is performed, Exchange makes temporary copies of the database file (.edb file) and the streaming database file (.stm file). Tables from the .edb file are preserved and copied into the temporary database, but empty pages and indexes are discarded. Because this causes physical page numbers in the database to be changed, pages are not copied unaltered; the page links between them are all updated, and all pages left in the database undergo integrity checks. All pages in the .stm file that has information on them are preserved in the temporary .stm file, and references to the pages are updated in the .edb file.
How Long Does it Take to Defragment a Database?
The time length to complete defragmentation depends on how much of the database is empty, and not on the size of the database file. For example, defragmenting a 100 GB database that contains 10 GB of data takes about the same time as defragmenting an 11 GB database that contains 10 GB of data.
By default, after defragmentation is completed, the temporary database automatically becomes the new production database, and the original production database is deleted. The time that defragmentation takes can be significantly reduced if you have as much free space on the same logical drives as the size of the original database files. In this case, the temporary database can be put on the same logical drive, and the final copy will complete almost instantly.
We do not recommend that you use a network drive to hold the temporary database. When you use a network drive for the temporary database, defragmentation will take longer, and any transient or permanent network error will end the process. Because defragmentation cannot be resumed, you would have to start over from the beginning.
Note:
You only need as much extra logical drive disk space as the final size of the files after defragmentation. Although it is impossible to exactly predict how much disk space will be reclaimed, you should leave a recommended 110% of free disk drive space to be safe. For more information about how to determine the amount of disk space for defragmentation, see the Microsoft Knowledge Base article 195914, "Determining database free space with Exchange 5.5 Service Pack 1 and later versions of Exchange" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=195914).

When to Run Eseutil /D?
There are several situations where it is appropriate to run Eseutil /D to defragment an Exchange database. The following includes a list of those situations:
· There is a significant amount of white space in the database that can be reclaimed and which will not be reused. An example can be when the number of mailboxes in the database has been significantly reduced.
· An event is repeatedly logged in the Application log advising you to defragment the database offline. This may occur rarely when typical online defragmentation is no longer able to efficiently defragment the database.
· When the 16 GB database size limit is reached on the Standard version of Exchange and white space must be reclaimed in order to mount the database. If you are running Exchange Server 2003, then Service Pack 2 (SP2) should be installed to raise the limit to 75 GB. For more information about increasing the database size limit, see Microsoft Knowledge Base article 828070, "Exchange Server 2003 mailbox store does not mount when the mailbox store database reaches the 16 GB limit" (http://go.microsoft.com/fwlink/?linkid=3052&kbid=828070).

Note:
After defragmenting the database using Eseutil, we recommend that you perform a full backup of the database. A full backup is needed because the database defragmentation creates new database files which have new database signatures. Log file replay after the restore depends on database signatures to match the expected values recorded in transaction log files. Any database backups that are taken before the defragmentation will contain database files that have signatures different from the new defragmented database. If an older database is restored, the new transaction logs which are bound to the new defragmented database files will not replay.

When not to Run Eseutil /D?
There are situations where it is not appropriate to run Eseutil /D to defragment an Exchange database. The following includes a list of those situations:
· Eseutil defrag should not be run as any kind of standard maintenance. Exchange runs an automatic online defragmentation nightly that handles the day-to-day maintenance of Exchange. There is no reason to periodically run an offline defragmentation unless special circumstances apply.
· Eseutil defrag cannot not be run when the database is not in a consistent state.
Note:
As a rule, unless you expect more than 20 percent of available space to be recovered, defragmentation will likely not cause permanent shrinkage of the database files.