Windows 2000 and Windows Server 2003 Active Directory allows you to edit the Schema and add additional attributes to it. These attributes can be easily connected to existing Object Classes such as users, groups, computers and so on.

Adding items to the Schema, also called “extending the Schema”, or even modifying existing objects can be a tricky business, and if done without proper knowledge, can be very destructive to your existing Active Directory infrastructure. This is because the Schema is a forest-wide setting, and any additions or changes to the Schema will be immediately replicated to each and every Domain Controller in each and every domain in your AD Forest. You cannot make any changes to the Schema and yet keep it within your domain’s boundaries. Furthermore, changing existing attributes (such as configuring an attribute to replicate itself to the Global Catalog) will cause a forest-wide replication of all the attributes and objects, even if your change was just made on one attribute. Note that this behavior was changed in Windows Server 2003, but even so, you might unintentionally cause a major network load and a lot of overhead by simply clicking one one small checkbox on one small attribute.

Many articles talk about adding items and extending the Schema. However on this article I wish to show you a simple method of adding attributes to the Schema, and by using these examples you can modify them and use them for your own purposes.

Requirements

Warning! First, let me stress the fact that the Schema is not a child’s play. If you don’t know what you’re doing – stop now. Go read a good book about AD, consult a knowledgeable friend, go play with traffic. Don’t blame me if you mess up your corporate network because you’ve made careless changes to the schema. Read my lips: I will not be held responsible for any of your actions, and for any of the results that follow these actions.

Now, read ahead.

In order to extend the Schema you’ll need to be a member of the Enterprise Admins and Schema Admins groups. These groups are part of the AD Forest Root Domain, and if you’re not already a member of these groups, then it probably means that you have no business in messing with the Schema in the first place.

Next, in most cases, you’d be better off by doing this on the Domain Controller that is holding the Schema Master FSMO role (read more about Understanding FSMO Roles in Active Directory).

Register the Active Directory Schema snap-in in order to later use it from an MMC window

1. Open the Run command and type:

regsvr32 schmmgmt.dll

You should get a confirmation message.

1. Next, open Run and type mmc.exe. Press Enter.
2. In the new MMC window, click File > Add/Remove Snap-in.
3. Click Add, then, in the Add Standalone Snap-in window, select the Active Directory Schema snap-in from the list. Next click Add again.
4. Click Ok.

Windows 2000 only – Enable write operations to the Schema

If you’re running Windows 2000-based AD, you’ll probably need to allow the Schema to be written. To do so follow these guidelines (only required for W2K-based DC):

1. In the MC window from the previous procedure, under the Console Root, double-click on the Active Directory Schema snap-in and let it load (you’ll know when it has loaded when you will see 2 nodes under the root – Classes and Attributes)
2. Right-click Active Directory Schema (your domain controller name) and

Adding 3 new attributes to the Schema

One method of creating new attributes in the Schema is by using the Active Directory Schema snap-in from an MMC.

In order to use this snap-in you must first register it with the following command:

regsvr32 schmmgmt.dll

Connecting the new attributes to the User Object Class

One method of creating new attributes in the Schema is by using the Active Directory Schema snap-in from an MMC.

In order to use this snap-in you must first register it with the following command:

regsvr32 schmmgmt.dll

The results

After adding the new attributes we now need to verify their existence and functionality.

What now?

After the new attributes were successfully added to the Schema and we’ve verified their functionality, we would now like to begin working with these attributes and begin populating their vales.

http://www.petri.co.il/add_additional_attributes_to_user_objects.htm

Exchange Mailbox Quota Types

Mailbox quotas can be set at the database or mailbox level.  Quotas set at the mailbox level will take precedence over database quotas.  Additionally, quotas can be a hard limit, preventing sending and/or receiving e-mail, or just a warning threshold which triggers a warning message.  It’s important to choose the right type of quotas to set – do you want users to be warned about their mailbox size, or do you want to prevent them from sending or receiving e-mail if they exceed their quota? The three mailbox quota types are:

Issue Warning Quota –

this is not a hard limit, but a warning threshold.  When it has been exceeded the user will get a warning message about their mailbox size, but will still be able to send and receive e-mail.

Prohibit Send Quota

this is a hard limit, and once a mailbox size exceeds it the user will no longer be able to send e-mail, but will still be able to receive e-mail.

Prohibit Send and Receive Quota –

this is also a hard limit, and once it is exceeded the user will no longer be able to send or receive e-mail messages.  Incoming e-mail will be returned to the sender.

Customizing Quota Messages

To make things easier for users, and to reduce the number of calls to the helpdesk, the messages which Exchange sends when a user is exceeding a quota limit can be customized to include more useful or practical information than the standard message gives.  Custom quota messages also support HTML, so you can include formatting or other HTML, such as link to a self-help knowledgebase article offering tips on reducing mailbox size.  In previous versions of Exchange modifying the quota messages was difficult and usually required programming skills, or custom DLL files, but with Exchange 2007 it can all be done with the PowerShell command line.

While there are only three mailbox quota types, there are four quota message types as a warning quota can be set with or without a hard limit quota.  Custom messages can be set for all four quota message types:

WarningMailboxUnlimitedSize –

this message type is sent to mailboxes which have no size limit when the warning quota has been exceeded.

WarningMailbox –

this message type is sent to mailboxes which have a size limit (such as a Prohibit Send or Prohibit Send and Receive quota) when the warning quota has been exceeded.

ProhibitSendMailbox –

This message type is sent when the Prohibit Send storage quota is exceeded.

ProhibitSendReceiveMailBox –

This message type is sent when the Prohibit Send and Receive storage quota is exceeded.

The New-SystemMessage cmdlet is used to set a custom quota message:

This command will set an HTML custom message which includes a hyperlink:

Once a custom quota message has been set it can be viewed using the Get-SystemMessage cmdlet:

It can be modified using the Set-SystemMessage cmdlet:

And it can be removed using the Remove-SystemMessage cmdlet:

Quota messages are sent according to a schedule defined on each mailbox database.  The default schedule is daily, between 1am and 1.15am.  The schedule can be altered using the Set-MailboxDatabase cmdlet.

This command will set the database “Mailbox Database” on server “EXCHANEG01” to send quota notifications on Sundays and Wednesdays between 7am and 8am:

You must be delegated the Exchange Organization Administrator role to use the *-SystemMessage cmdlets.  You must be delegated the Exchange Server Administrator role and be a member of the local Administrators group for the target server to use the Set-MailboxDatabase cmdlet.

Retrieving Mailbox Sizes and Quotas

Mailbox sizes are retrieved using the Get-MailboxStatistics cmdlet.

Mailbox Quotas are retrieved using the Get-Mailbox cmdlet.

This simple script combines Get-MailboxStatistics with Get-Mailbox to show mailbox size and prohibit send quota in one command:

You must be delegated the Exchange View-Only Administrator role to use the Get-Mailbox and Get-MailboxStatistics cmdlets.

Setting Mailbox Quotas

Mailbox quotas can be set in two places – directly on the mailbox or on the mailbox database.  By default Exchange 2007 sets a quota of 2000MB on all new mailbox databases, and all mailboxes in the database inherit this value.

The Set-MailboxDatabase cmdlet is used to set default quotas on a mailbox database using the PowerShell command line.

This command will set the default warning quota on the database “Mailbox Database” on server EXCHANGE01 to 975MB, and the limit at which users will no longer be able to send mail to 1000MB:

The Set-Mailbox cmdlet is used to set quotas on individual mailboxes.

This command will set the warning quota for user juser to 1475MB, and the limit at which the user will no longer be able to send mail to 1500MB.  It will also configure the mailbox not to use the database default quotas:

Quota increase requests will be fairly common for most organizations which use mailbox quotas.  Quota increases are usually governed by an IT policy, and increases are usually in fixed amounts.  This PowerShell script will automatically increment the quota size of a specified mailbox by a given amount. This script, or something like it, can be used to decrease the administrative overhead of mailbox quotas.  The script reads the current quota from the database or from the mailbox, shows what the existing quota is and what the new quota will be, then prompts for confirmation before setting the new quotas. It then displays confirmation that the new values have been set.  If the current quota is not a multiple of the increment specified it will be rounded up to the next increment, rather than having an increment added, which ensures that quotas are always a multiple of the desired increment value.

You must be delegated the Exchange Recipient Administrator role to use the Set-Mailbox cmdlet

Configuring the Mailbox Information Cache Refresh Interval

Exchange quota information is stored in Active Directory, and by default is cached by Exchange for up to two hours.  This means that it could take up to two hours for a quota change to take effect.  The recommended interval for Exchange to refresh quota information is 20 minutes, which can be set by adding three registry values.

Note – setting the cache refresh intervals too low can adversely affect the performance of Exchange.  Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved.  Before editing the registry, back up any valuable data.  You need to be a local administrator on the Exchange server in order to edit the registry.

1. Start the registry editor on your Exchange 2007 Mailbox server
2. Locate the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem key.
3. Create the “Reread Logon Quotas Interval” value
   1. Right-click ParametersSystem, select New, and then select DWORD value.
   2. Name the new DWORD value “Reread Logon Quotas Interval”.
   3. Right-click Reread Logon Quotas Interval, and then click Modify.
   4. Enter a decimal value of 1200 seconds (20 minutes)
4. Create the “Mailbox Cache Age Limit” value
   1. Right-click ParametersSystem, select New, and then select DWORD value.
   2. Name the new DWORD value “Mailbox Cache Age Limit”.
   3. Right-click Mailbox Cache Age Limit, and then click Modify.
   4. Enter a decimal value of 20 (20 minutes)
5. Locate the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchange ADAccess key.
6. Create the “CacheTTLUser” value
   1. Right-click MSExchange ADAccess, select New, and then select Key.
   2. Name the new key Instance0.
   3. Right-click Instance0, select New, and then select DWORD value.
   4. Name the new DWORD value “CacheTTLUser”.
   5. Right-click CacheTTLUser, and then click Modify.
   6. Enter a decimal value of 300 (5 minutes)

Alternately, copy this text file and paste it into a file called MailboxCache.reg, then import it into the registry of each of your Exchange 2007 Mailbox servers

The Exchange Information Store service needs to be restarted for the change to become effective.  More information about these changes can be found on the Microsoft TechNet web site.

Let me explain how archive mailbox feature will address the existing problems.

• There is no company which doesn’t have staff using PST files. Archive mailbox gets rid of PST files by giving the user an additional mailbox.
• PST files are local to the user’s machine, gets corrupted easily and is hard to include the files in backup. Archive mailbox sits in the same mailbox database as the user’s main mailbox and can be included in the backup easily.
• Archive Mailbox is available in Outlook as well as Outlook Web App (OWA), which is a huge improvement. Users can access their email archive irrespective of where they are.
• Archive Mailbox is included as part of the Exchange Enterprise CALs and hence no extra cost is required (for those who have ECALs).
• Retention policies can be set for emails/folders in the archive mailbox.
• User has the option to search for emails in archive only or both primary & archive mailbox.
• Archive Quota can be set separate to the primary mailbox.
• Emails in existing PSTs can be dragged into the archive mailbox very easily.
• Users get Conversation View scoped to archive mailbox as well.
• The archive and primary mailbox share the same user account.
• Only one archive mailbox can be configured for a user.
• Archive mailbox gets created on the same mailbox database as the primary one, which is a drawback. Future service packs might bring the option to create the archive mailbox in a different database.
• The default quota warning for the archive mailbox is 10GB, which can be changed.
• All in all, it is good news for admins as they don’t have to worry about issues like a lost laptop with PST files in it, corrupted PSTs etc.

How To Configure Archive Mailbox?

Configuring an archive mailbox is very easy. You can configure an archive mailbox while the user account is created. Just check the box in the wizard!

To configure archive mailbox for an existing user, launch EMC & navigate to Recipient Configuration, right click the user and select “Enable Archive”.

A windows prompt reminds that an enterprise CAL is necessary. Click OK and an archive mailbox is configured for the user.

Note that the icon denoting a user with archive mailbox is different to the normal users.

Select the properties of the user and navigate to the “Mailbox Features” tab. You can see that the archive mailbox feature is enabled and selecting the properties brings up a box to give a name for the archive mailbox. The default name is “Online Archive – Username”. You can give a different name if you want to.

In order to change the default quota warning, navigate to “Mailbox Settings” tab, select Archive Quota –> Properties.

Launch Outlook 2010 and you will see that the archive mailbox is displayed. You can create new folders, move emails, set retention policies etc.

Launching Outlook Web App (OWA) gives the same look and feel & your archive mailbox is available for sure!

Related Links :
http://www.microsoft.com/exchange/en-us/email-archiving-and-retention.aspx
http://technet.microsoft.com/en-us/library/dd979795.aspx

• Using the Exchange Management Shell (EMC)
• Using the Exchange Management Console (EMS)
• Using the performance monitor

We’ll go through each of these in order, and cover what you need to know to use whichever method you prefer as effectively as possible. At the end of this article, I’ve provided a table which compares all methods, so you can decide which will work best for you.

Exchange Management Shell

To explode the number of options available to us even more, when using the EMS, we actually have several cmdlet options to monitor the move requests:

• Get-MoveRequest
• Get-MoveRequestStatistics
• Get-MailboxStatistics

Get-MoveRequest

Let’s start with the first one, Get-MoveRequest; by itself, this Powershell cmdlet will only give you a brief overview of the move requests which are currently active or queued. Without using the |fl command in the pipeline, it will only display:

• displayname
• status
• targetdatabase

Which may , in some cases, be enough, particularly if you only want an overview of the move-requests currently active or queued, and you’re not interested in more detailed information. The returned displayname and targetdatabase fields don’t really need any further explanation, but what about the status field? This field will give the current status of a mailbox move, and will report one of the following status values:

• AutoSuspended – the move request is currently suspended; it can only get this status if you’ve used the SuspendWhenReadyToComplete parameter when submitting the move request. The SuspendWhenReadyToComplete parameter will allow the mailbox move to start, but the move will be suspended when it reaches the CompletionInProgress status, which we’ll come to in a moment.
• Completed – the move request has been completed.
• CompletedWithWarning – the move request has been completed with at least one warning, which can happen due to several reasons; For example, if the old mailbox could not be cleaned up
• CompletionInProgress – the move request process is performing the last sync with the old mailbox before the new mailbox is marked as active.
• Failed – the move request has failed, which can happen due to several reasons; for example, the permissions set on specific folders might be corrupted, or the maximum number of bad items is reached.
• InProgress – the Microsoft Exchange Mailbox Replication service (MRS) is currently moving the mailbox.
• Queued – the move request is currently waiting to be picked up by the Microsoft Exchange Mailbox Replication service (MRS).
• ReadyToComplete – the move request has been suspended, and is now waiting for a manual action from the administrator before it can be completed.
• Suspended – the move request is currently suspended, which can be the result of using the suspend parameter when submitting the move request. When using the suspend parameter, the move will still be submitted, but the actual move will not start until the Resume-MoveRequest cmdlet is performed.

Of course, the information displayed by the Get-MoveRequest cmdlet by itself may not be sufficient for some cases. For example, if you would like to know what kind of move is being performed, or if the mailbox is available during a move, you’re going to need more information. In these kinds of situations, you’ll need to add |fl to the cmdlet, which will make some additional information available:

As you can see in the screenshot above, there are a few fields which might be very useful when monitoring the move process:

• Flags – this reports which options are being used for the move, such as CrossOrg, Pull, Offline, or RemoteLegacy. This information will tell you if a mailbox is being moved from another forest which runs, for example, Exchange 2003, and that the mailbox is not available during the move.
• MoveType – this field reports the type of move which is being performed, and is more generic than the Flags field. For example, CrossOrg (from another forest), or IntraOrg (from another Exchange server in the same forest)
• Direction – the possible values of this field are pull or pushed; pull can be seen when performing a migration from another Exchange server, whereas pushed can be seen when moving a mailbox to another Exchange server. So if, for example, we start a mailbox move on an Exchange 2010 server which will migrate a mailbox from an Exchange 2003 server, this is a pull migration. If, on the other hand, a mailbox move is started on an Exchange 2010 server which will move the mailbox to another Exchange 2010 server, this will be a pushed migration.
• IsOffline – This tells us whether the mailbox is available during a move. If the value is true, then the mailbox will not be available, and if of the value is false then the mailbox will be available.

As you see, the additional output will provide some extra information, but won’t provide a detailed status overview of how long each step took or answer questions like “how many megabytes are transferred?”, “what was the time needed to perform the move?”, “what is the current bytes-transferred-per–minute?”, and, in case of CompletedWithWarning, “what is the problem that occurred?”.

Get-MailboxRequestStatistics

If you would like to see this kind of fine-grained information, then you’ll need to use the Get-MoveRequestStatistics cmdlet which, as the its name implies, will give you detailed information about the move. Without using the |fl pipeline, this cmdlet will display:

• Displayname
• Status
• TotalMailboxSize
• TotalArchiveSize
• PercentComplete

This information will give you a good overview of the current status of a move, and since the identity parameter is required for this cmdlet, it will also display the details of only one move request. To get an overview of all the move-requests currently active or queued, you can pipe the output from the Get-MoveRequest cmdlet as input for Get-MoveRequestStatistics:

This will give an overview similar to what you can see below:

Fig. 2 Piping the Get-MoveRequest cmdlet into Get-MoveRequestStatistics

In addition, just like the Get-MoveRequestcmdlet, the Get-MoveRequestStatistics cmdlet will give a lot more information when used in conjunction with the |flcommand. Of course, compared to using |flwith Get-MoveRequest, the Get-MoveRequestStatisticscmdlet by itself will already provide plenty of information which is very useful when troubleshooting move requests. Nevertheless, below is a screenshot of the output of the Get-MoveRequestStatistics cmdlet with the |fl command:

Fig 3. Using Get-MoveRequestStatistics with the |fl command.

Bear in mind that this will not necessarily be very useful when done in combination with the pipelined GetMoveRequest|Get-MoveRequestStatisticscmdlets, as this will potentially generate a huge and unreadable overview.

But what if you want to use the Get-MoveRequest|Get-MoveRequestStatistics command, but would like to display information which is only available when using the |fl parameter? Well, in that case, you can use the Select parameter, which will give you the option to just select a subset of the complete overview. For example, if we want to get an overview of the move requests which will display the following information:

• Only move requests which are currently active and have the status InProgress will be shown,
• The Displayname of the mailbox should be displayed,
• The percentage completed should be displayed,
• The size of the mailboxes should be displayed,
• The current MB/s should be displayed.

Let’s start with the first part, generating an overview of move requests which are currently InProgress:

Now that we know which moves are currently active, we need to gather some extra details about the move. As mentioned earlier, we will need to pipeline the results into the Get-MoveRequestStatisticscommand to gather the additional information. To get the displayname, percentage completed, size of the mailbox and the bytes transferred per minute, we will need to use the fieldnames available from the Get-MoveRequestStatistics cmdlet. So in this case, DisplayName, PercentComplete, TotalMailboxSize and BytesTransferedPerminute:

When combining these two cmdlets, you will get the command like this:

…which will give the following result:

Fig 4. Specifying exactly what information you want to retrieve from the pipelined Get-MoveRequest and Get-MoveRequestStatistics cmdlets.

As you may already know, you will need to clean up the move request manually by running the Remove-MoveRequest cmdlet. Once you’ve performed that cleanup, you won’t be able to use the Get-MoveRequest and Get-MoveRequestStatistics cmdlets anymore. However, it’s still possible to view the move request history by using the Get-Mailbox cmdlet together with the IncludeMoveHistory parameter. Alternatively, if the request hasn’t been removed yet, you can use the IncludeMoveReportparameter to find out plenty of useful details. The difference between the parameters, besides the fact that IncludeMoveReport is not available once the move request has been cleared, is the information which will be provided to you:

Specifically, the difference between the two parameters is the amount of information you will receive. If you just want to know certain specific information about the last completed move – date and time, target database, size of the mailbox and the duration of the move process – then you can use the IncludeMoveHistory parameter:

…which will give the following result:

Fig 5. The result of using the IncludeMoveHistory parameter in a Get-MailboxStatistics cmdlet.

However, if you want some more detailed information, then the last option available is to use the IncludeMoveReport parameter. This parameter is very useful when troubleshooting a move request and not enough information is provided by the Get-MoveRequestStatistics |fl cmdlet, as the parameter will cause a verbose log of the move request to be generated. This log contains a lot of data, and for this reason I recommend to output the command to a CSV file using the Export-csv cmdlet. The complete command will then look like this:

The second method we will consider is monitoring move requests using the Exchange Management Console (EMC). Although it does not provide as much information as when using the cmdlets, it will still give a good overview of the move requests submitted to the server. The move requests can be found under: Recipient Configuration > Move Request.

Fig 6. The Move Request option in the EMC

This will give an overview of all current move requests, including the completed ones, which are displayed by default, and which (if you don’t want them displayed) you will have to manually remove using the Clear Move Request option on the right side of the screen.

When getting the properties of a move request, the following information will be displayed:

Fig 7. The mailbox move information displayed by the EMC.

As you can see it gives a relatively complete overview of the move, including the following information:

• Current status
• Percentage completed
• Duration
• Mailbox size
• Corrupted items
• Source database
• Target database

Normally this should be enough information if you just want to know more about a move request than just its status. The only disadvantage of this method, compared to the PowerShell cmdlets, is that you will need to get the properties of each move request separately.

The details tab will not give you a lot of additional information besides the database versions and the start, queued and completed times for this particular move. However, new in Service Pack 1 is the ability to view the move report, as is available in the Exchange Management Shell when using the IncludeMoveReport parameter. Below is an example of the move request log:

Fig 8. The mailbox move report, as now available in Exchange Server 2010 SP1.

As you can see, huge amounts of information are now made available, which will make a huge difference if you need to troubleshoot a mailbox move request. Compared to the RTM version of Exchange Server 2010, Microsoft has made some improvements to the EMC which I personally think provide a significant benefit, even if we’re just considering this reporting functionality.

Using Performance Monitor a.k.a. Perfmon

When you saw this method mentioned earlier in this article, you may have been a little incredulous. Yes, you can monitor the move-requests using Perfmon, and it may be very useful when, for example, you want view the transfer rate in real-time. The counters which you can use to monitor the requests can be found under the category MsExchange Mailbox Replication Service per MRS Instance:

Fig 9. The appropriate Perfmon Counters for monitoring mailbox moves.

Interesting counters to have a look at during the move requests are:

• Active Moves: Bytes Transfered – the total amount of bytes moved.
• Active Moves: Transfer Rate (KB/sec) – the current transfer rate of the move requests.
• Move Requests/Hour – the average amount of move requests completion per hour.

These are just a few counters, but in total there are more than 60 counters which can be used to monitor the process, and it’s worth experimenting with them to discover how best to employ them. A complete overview of the available counters is available from Microsoft TechNet.

Comparison

So, to help you decide when to use which method for retrieving the correct information, I created a handy table. It does not contain all the available fields, as this would create an enormous table, so I just picked the most import fields to make sure it gives a useful overview:

Conclusion

In this article we’ve discussed several methods for monitoring the process of moving the mailboxes and, compared to the monitoring options available in Exchange 2003, the monitoring process has been vastly improved. Which method you will use will depend on several things, such as the number of mailboxes which you are moving, and the information you want to see.

We’ve also seen a recent addition to the monitoring options in the form of the detailed report now available from the EMC in Exchange Server 2010 SP1. Compared to Exchange 2010 RTM, I think that feature is an excellent decision on Microsoft’s part, as many (if not most) administrators don’t necessarily use PowerShell yet. That being said, I strongly recommend that you start to use PowerShell, as it will give you a lot more options throughout your administration tasks, not only when monitoring the move mailbox process.

http://www.simple-talk.com/sysadmin/general/monitoring-mailbox-moves/

If you have an Exchange Server 2003 environment you may want to skip Exchange Server 2007 and move directly to Exchange Server 2010. The easiest way to achieve this is to integrate Exchange Server 2010 into the existing Exchange Server 2003 environment, a so called intra-organizational migration. This is also known as transitioning from Exchange Server 2003 to Exchange Server 2010. But what does it take and what issues might arise?  This is part 1 of a series of two about moving from Exchange Server 2003 to Exchange Server 2010 and in this document I’ll show you what’s needed before you start moving mailboxes from Exchange Server 2003 to Exchange Server 2010.

Exchange Server 2003

Suppose we have a fictitious company called Inframan, which is a consulting company specializing in bridges, tunnels, buildings etc. Inframan has approximately 500 employees, 50 employees are working in the office, 450 employees are working ‘in the field’. Employees within the office have their own desktop which connects to an Exchange 2003 Mailbox Server using Outlook 2003 and Outlook 2007. Employees outside the office connect to the office using their company laptop with Outlook 2007 and Outlook Anywhere and with Windows Mobile devices. When needed they can use their PC at home to use Outlook Web Access to access their mailbox. Typical usage profile is “light”, approximately 25 messages are received per day and 10 messages are sent per day, per user that is. Behind the firewall is an ISA Server 2006 acting as a reverse proxy to publish all Exchange Services to the Internet. Inframan’s environment will look something like this:

Inframan is using only one namespace for accessing all services from the Internet: webmail.inframan.nl. This is used for Outlook Web Access, Outlook Anywhere and Windows Mobile devices.

Recently Inframan has been thinking about upgrading to Exchange Server 2007, but they decided to move directly to Exchange Server 2010.

Coexistence with Exchange Server 2010

Exchange Server 2010 can easily coexist in a Exchange Server 2003 organization as long as the Exchange Server 2010 prerequisites are met:

• The Active Directory forest needs to be in Windows Server 2003 forest functionality mode;
• All domains that contain Exchange recipients need to be in Windows Server 2003 domain native mode;
• The Global Catalog Servers and the Active Directory Schema Master need to be at a minimum level of Windows Server 2003 SP1 (which equals to Windows Server 2003 R2);
• The Exchange 2003 organization needs to be running in ‘native mode’;
• Link State updates on all Exchange Server 2003 servers need to be disabled according to Microsoft knowledge base article ‘Suppress Link State Updates’

Be careful when upgrading your Active Directory Domain Controllers since not all versions are supported to run with Exchange Server 2003. For a complete overview check the Microsoft Technet Site: http://technet.microsoft.com/en-us/library/ee338574.aspx.

Inframan will build two new Exchange Server 2010 servers, one combined Hub Transport Server / Client Access Server and one dedicated Mailbox Server. These Servers will be installed in the same Windows Server 2003 Active Directory domain as the Exchange Server 2003 organization. This will greatly improve the ease of moving mailbox from Exchange Server 2003 to Exchange Server 2010.

Moving from Exchange Server 2003 to Exchange Server 2010 in the same Active Directory forest is called transitioning. Building a new Active Directory forest with a new Exchange Server 2010 organization and moving mailboxes from the old Active Directory to the new Active Directory is called migrating.

The interim messaging environment, where both Exchange Server 2003 and Exchange Server 2010 coexist in the same Active Directory domain will look like this:

In Exchange Server 2007 Internet clients could connect to the Exchange Server 2007 Client Access Server while the mailbox was still on Exchange Server 2003. The Client Access Server retrieves the data out of the mailbox and sends it back to the Internet client. In Exchange Server 2010 this has changed. When a client connects to Exchange Server 2010, it actually connects to the Exchange Server 2010 Client Access Server and if the mailbox is still on the Exchange Server 2003 Mailbox Server then the client is redirected to the Exchange Server 2003 front-end server. This front-end server then handles the connection request. This automatically means the namespaces of the Exchange environment will change. For Inframan this means that the following namespaces are used:

• https://webmail.inframan.nl – This is used by all Internet clients that connect to the Exchange environment. This name is not different than in the Exchange Server 2003 namespace, but it will now point to the Exchange Server 2010 Client Access Server;
• https://autodiscover.inframan.nl – This is used by Outlook 2007 and (Outlook 2010) clients for autodiscover purposes;
• https://legacy.inframan.nl – This will be the new namespace for the Exchange Server 2003 front-end server. This automatically means that the namespace for the Exchange Server 2003 front-end server is going to change!

The servers that will hold the Exchange Server 2010 server roles have the following prerequisites:

• The servers need to be running on Windows Server 2008 or Windows Server 2008 R2;
• .Net framework 3.5 with SP1 needs to be installed;
• PowerShell 2.0 needs to be installed;
• Office 2007 Filter packs needs to be installed for the Hub Transport Server role and the Mailbox Server role;

Make sure that after installing Windows on the servers that they are up-to-date with the latest hotfixes and service packs.

The first step for Exchange Server 2010 Server is to upgrade the Active Directory schema to contain the Exchange Server 2010 extensions. This is achieved by using the Exchange Server 2010 setup application followed by a number of parameter:

Setup.com /PrepareLegacyExchangePermissions – Exchange Server 2003 uses the Recipient Update Service to stamp the user with the appropriate Exchange attributes during provisioning. This is replaced in Exchange Server 2010 by E-Mail Address Policies. The /PrepareLegacyExchangePermissions parameter changes security settings so that both the Recipient Update Service and E-mail Address Policies can coexist in the same Active Directory;

Setup.com /PrepareSchema – This command upgrades the Active Directory schema to include the Exchange Server 2010 extensions. This can be checked by using ADSIEDit and checking the value of the UpperRange parameter of the  CN=ms-Exch-Schema-Version-Pt object in the Schema. This should have one of the following values:

Note that the value is the same in Exchange Server 2007 service pack 2 and in Exchange Server 2010 RTM – this is because Exchange Server 2007 service pack 2 will install the Exchange Server 2010 schema extensions.

Setup.com /PrepareAD – This command upgrades the Exchange organization, which is stored in the configuration partition in Active Directory to support Exchange Server 2010. In Exchange Server 2003 information is stored in the “First Administrative Group” or perhaps more if you created additional Administrative Groups. The Exchange Server 2010 setup application will create a new Administrative Group called “Exchange Administrative Group (FYDIBOHF23SPDLT)” where all Exchange Server 2010 configuration information is stored. This will be visible in the Exchange Server 2003 System Manager:

Setup.com /PrepareDomain – This is the last step in preparing the Active Directory and will create all necessary groups in the domain being prepared.

When Active Directory is fully prepared we can continue with installing the first Exchange Server 2010 server in the environment. For our example, this has to be the combined Hub Transport and Client Access Server. Start the graphical setup program (setup.exe) and download the Language File bundle if needed. If you select “install only languages from the DVD” only the language setting of your DVD (for example English or French) will be available. This is used not only for the language of the Exchange Server, but also the available language settings for the clients being used.

During the installation of the combined Hub Transport and Client Access Server a so called ‘custom setup’ will be used. This means we can select which server roles will be installed. In the Inframan example the following needs to be selected during setup:

When continuing the setup application a window will be shown asking if this Client Access Server is Internet facing and if so, what the external domain will be. This is an important step because it configures the Client Access Server automatically with the appropriate settings. Check the “The Client Access server will be Internet-facing” option and enter the external domain name. This is “webmail.inframan.nl” in our example.

Exchange Server 2003 uses Routing Groups to determine the proper way to route messages while Exchange Server 2010 uses Active Directory sites for routing. These are not compatible with each other so a legacy Routing Group Connector will be created within Exchange Server 2010. This legacy connector connects Exchange Server 2010 with Exchange Server 2003 so messages can be sent between the two Exchange versions. During setup of the first Hub Transport Server an Exchange Server 2003 Hub Server needs to be selected. This is the server the legacy Routing Group Connector will connect to:

Note that this choice can be changed and/or added to after setup is complete.

Now finish the setup wizard and install the Client Access and Hub Transport Server roles on this server.

It is also possible to use the command line setup application to setup the above mentioned configuration. Open a command prompt, navigate to the installation media and enter the following command:

Mailbox Storage Design

Before installing the Exchange Server 2010 Mailbox Server role a proper storage design has to be made. Microsoft has recently released the new storage calculator, which is now called the “Exchange 2010 Mailbox Server Role Requirements Calculator” and can be downloaded here:

http://msexchangeteam.com/archive/2009/11/09/453117.aspx.

The Requirements Calculator needs to be used for a proper storage design. The following variables are used in the Requirements Calculator for our example:

The Requirements Calculator will show the following results:

An interesting part of Exchange Server 2010 is the database technology. Microsoft has made significant changes to the database structure to lower the disk performance requirements. It should be sufficient to run the Mailbox databases and its accompanying log files from SATA disks.

In the Requirements Calculator there’s the possibility to enter the disk configuration. For the new Inframan Mailbox server 7.200 RPM SATA disks with a capacity of 500 GB will be used for storing the databases and 7.200 RPM SATA disks with a capacity of 250GB will be used for storing the log files. This disk configuration is not exactly a high end configuration, but it is by far the most cost effective solution.

The Requirements Calculator contains a tab called “Storage Design”. When using the above mentioned values the Calculator recommends a RAID1/0 configuration with 6 SATA disks for storing the Mailbox Databases and a RAID1/0 configuration with 2 SATA disks for storing the Log Files.

Installing the Mailbox Server role

When the storage solution has been properly designed and implemented the Exchange Server 2010 Mailbox Server role can be installed. As with the Client Access and Hub Transport Server roles make sure you download the Language Pack during setup. Select a ‘custom setup’ and select only the Mailbox Server role when you get to the ‘Server Role selection’ window as shown in Figure 5. Finish the setup wizard and install the Mailbox Server role. After installation of the 2^nd server the organization is ready to be configured and we can prepare for start moving mailboxes from Exchange Server 2003 to Exchange Server 2010.

Configuring the Exchange Server 2010 servers

When both Exchange servers are installed it is time to configure the Exchange environment properly before Exchange Server 2010 can be used and mailboxes can be moved. The following needs to be configured:

• Relocate the Mailbox Databases on the new storage solution;
• Unified Communications certificate on the Client Access Server;
• New server certificate on the Exchange 2003 front-end server;
• OWA 2010 needs to be configured for use with Exchange Server 2003;
• Public Folder replication.
• A send and receive connector also have to be configured, but I will describe this in the next article when the mail flow will be changed from Exchange Server 2003 to Exchange Server 2010.

Relocate the Mailbox Databases

On the new Mailbox Server there are two drives, from a hardware perspective configured as outlined before. These drives are F:\ for the Mailbox Databases and the Public Folder database and drive G:\ for the Log Files.

To change the location of the Mailbox Database open the Exchange Management Console and navigate to the Database Management, which can be found in the Organization Configuration. Right click the database and select “Move Database Path”. Change the Database file path to a directory on drive F:\ and change the Log folder path to a directory on drive G:\. Repeat this step for the Public Folder database.

If needed create new databases and locate the new database file on drive F:\ and the accompanying log files on driver G:\

Unified Communications Certificate

On the Exchange Server 2010 Client Access Server a new 3^rd party Unified Communications certificate needs to be installed. According to Microsoft knowledge base article 929395 (http://support.microsoft.com/kb/929395) the following Certificate Authorities are supported for use with Unified Communications certificates:

• Entrust – http://www.entrust.net/microsoft/
• Digicert – http://www.digicert.com/unified-communications-ssl-tls.htm
• Comodo – http://www.comodo.com/msexchange

However, most SSL Certificate Authorities can generate UC/SAN certificates that will work just fine. New in Exchange Server 2010 is the possibility to request certificates using the Exchange Management Console. Open the Exchange Management Console and select the Server Configuration in the navigation pane. Select the Exchange Server 2010 Client Access Server and create a new certificate request. For our environment we have to use the following domain names in our certificate:

• Webmail.inframan.nl
• Autodiscover.inframan.nl
• Legacy.inframan.nl

During the coexistence phase Internet clients will connect to the Exchange Server 2010 Client Access Server while their mailbox is still on Exchange Server 2003. The client request will then be redirected to the old Exchange Server 2003 front-end server. This server will therefore get a new FQDN (Fully Qualified Domain Name) and thus need a new certificate. This new FQDN will be legacy.inframan.nl.

OWA Configuration

During installation of the Exchange Server 2010 Client Access Server all settings have been configured for use on the Internet. The only thing that needs to be configured is the coexistence information for Outlook Web App. The Client Access Server needs to be configured in case a mailbox is still on Exchange Server 2003 and the client needs to be redirected to the Exchange Server 2003 front-end server.

On an Exchange Server 2010 server enter the following Management Shell Command:

This will make sure that when a user connects to Exchange Server 2010 Client Access Server for Outlook Web Access and the mailbox is still on Exchange 2003 the client will be redirected to the old Exchange Server 2003 front-end server.

Public Folder Replication

During installation of the Mailbox Server a new Exchange Server 2010 Mailbox Database will be automatically created. After installation you have to make sure that this database is moved from the default location to an alternate location for recovery and performance reasons.

A new Public Folder database will also be automatically created on the new Mailbox Server. The hierarchy, which is the structure of all Public Folders will be automatically replicated between all Public Folder Databases in the entire organization. The content replication of the Public Folders will have to be configured manually though.

To replicate the Offline Address Book and Free/Busy folders from Exchange Server 2003 to Exchange Server 2010 open the Exchange System Manager on the Exchange Server 2003 server and navigate to the System Folders in the ‘Folders’ folder in the First Administrative Group Navigate to the first Offline Address Book folder, right click it and select “All Tasks…”. The next is to select “Manage Settings”.

If you want to toggle between the System Folders and the normal Public Folders, navigate to the Public Folders, right click the Public Folders and select “View System Folders” or “View Public Folders”.

The “Manage Public Folder Settings wizard” will appear. Click Next on the Welcome page and select the “Modify lists of replica servers”. Follow the wizard and add the Exchange Server 2010 Mailbox Server role as a new replica. When finished, the folder and all its subfolders will be replicated to the Exchange Server 2010 Public Folder database. Repeat this step for the second Offline Address Book folder and the Schedule+ Free Busy folder.

Note: When the “Manage Settings” option is not available you can select “Properties” and select the replication tab to add the Exchange Server 2010 Public Folder Database.

The (default) Public Folder that are located on the Exchange Server 2010 Mailbox Server should be replicated to the Exchange Server 2003 Mailbox Server. To accomplish this logon to the Exchange Server 2010 Mailbox Server, open the Exchange Management Console and navigate to the Tools node. Under the Tools node open the Public Folder Management Console.

Right click the Offline Address Book in the results pane, select Properties and click the Replication tab.

Add the Exchange Server 2003 Mailbox Server to the replica list, the contents will now be replicated to the Exchange Server 2003 Mailbox Server. Be aware that Public Folder replication is a low priority mechanism, so it takes some time before both Public Folder databases are in sync.

Repeat these steps for the Schedule+ Free/Busy folder.

http://www.simple-talk.com/sysadmin/exchange/upgrade-exchange-2003-to-exchange-2010/

The Trouble with PSTs

As I already hinted, PSTs have their place, but can be problematic for the organizations that use them. In the majority of the cases that I have seen, PST files are used as a mechanism for circumventing mailbox quotas; if users want to keep more messages than a quota allows, then they can simply move the excess messages to a PST file, where they are outside of the administrator’s control.

Of course PST’s aren’t always used as a mechanism for circumventing administrative controls; they do have some legitimate uses. For instance, I recently read about one method for migrating public folder data to SharePoint 2010 that involved the use of PST files.

However, if PST files are primarily used as a repository for end user data then one has to question how valuable PST data really is. If an organization has a mailbox quota structure in place that forces users to delete all but the most important messages, then some administrators may assume that there is nothing within the PST files that would be of any benefit to the organization. This seems like reasonably sound logic on the face of it, though naturally not without it’s caveats, which I’m not going to delve into here. The problem with this philosophy is that some users may move all of their messages to a PST file and keep nothing in their mailbox. In situations like these, one cannot assume that there is no important data in the PST file, because it will most likely contain a mixture of important and unimportant information.

So why not just allow users to continue using PST files? Several reasons, actually. The biggest problem with PST files is that they are usually located on the user’s local hard drives, and are therefore never backed up. Indeed, even though PST files can be placed onto a network share, doing so violates Microsoft’s best practices and, more importantly, increases the chances of data corruption.

Another obvious problem with allowing PST files is that their use can lead to data theft. In situations where users are storing their messages in local PST files, anybody who has physical access to users’ computers could easily copy PST files onto removable media, and then open the files on another computer. While it’s true that the security risks can be reduced by simple steps such as encrypting workstations’ hard drives, many organizations do not take such precautions. I’m not even going to dwell on password-protecting PSTs, as there are plenty of free cracking tools available, and Microsoft themselves have acknowledged that the password protection is pretty weak.

Last but certainly not least, the use of PSTs as a method of data storage may lead to regulatory issues. In the United States, there are several different sets of regulations mandating that certain types of data be secured in specific ways. If messages containing sensitive data were moved to a PST file on a user’s local computer, it would almost certainly put the organization into a non-compliant state.

On the same note, some organizations configure default mailbox and custom mailbox folders with message retention policies, which allow messages to be kept for the legally required amount of time, and then disposed of according to company policy. Moving a message to a PST file circumvents any retention policies that may be in place, and may put the organization at risk legally.

This all boils down to one simple message: Exchange data should ideally be kept in Exchange, not PSTs. Moreover, any PSTs lurching on hard drives or shared drives should be imported back into Exchange so that their data payload can be properly managed. If space is an issue, then older messages can be archived, but exporting messages to PSTs is a foolhardy method for keeping your Exchange server a lean, mean machine.

Mailbox Quotas

If you’re still reading this, you presumably agree with the sentiment just expressed. At the very least, you are willing (I hope) to be convinced. However, before you rush off to import PST files with merry abandon, a word of caution: Regardless of the method that you are planning on using to import PST files into Exchange, special care must be taken to ensure that any existing mailbox quotas are large enough to accommodate the inbound data. Otherwise, the import process will likely fail for some mailboxes. It might seem like a trivial point to raise, but experience has taught me that it’s a point that occasionally needs reiterating.

How PST Importer Can Help

Red Gate Recently introduced a new product called PST Importer 2010 which, as the name suggests, is designed to import PST data into Exchange Server with no mess and no fuss. Of course, I realize that right now many of you might be wondering why you should bother using a third party tool for such a seemingly simple task. To be quite frank, you should use a third-party tool because Microsoft just doesn’t give you any other good tool for importing PST data.

Keep in mind that I’m not saying that Microsoft doesn’t give you any tools for importing PST data; it’s just that their process can be quite complex if you use the built-in tools and suggested methods, and the PST Importer is designed to make this process much easier.

Locating PST Files

So what is it about importing PST data that makes it such a challenge? Well, there are several steps involved in the task, each with their own hurdles, and the first involves actually locating the PST files that you want to import. These files are usually scattered among the users’ workstations and network shared drives. Unfortunately, Microsoft doesn’t provide you with any native Windows tools that can inventory all of the workstations on your network and produce a report detailing the locations of all of the PST files.

When working to find a non-third-party solution to this puzzle, fellow technical author James Allison developed a pair of WMI scripts that can search the network for PST files, and then create a CSV file detailing the network paths of each file. While I have no doubts that the script works, it requires administrators to open Port 135 on all of the machines they wish to search. This port is blocked by default by Windows Firewall because of the long history of malware exploits that rely upon accessing it. In addition, the script does not support NAT traversal, which may be an issue for some organizations.

With that in mind, I want to talk about how PST Importer 2010 locates PST files, and why it is a superior solution to the manual, WMI-scripting process. Before I do though, I wish to point out that I am in no way trying to discredit James Allison or his scripts, and I will be the first in line to say that he’s done a great service by providing a free alternative for those organizations that are unable to invest in a third party solution. Even so, I want to highlight the advantages of using a commercial solution over the free one, because I believe that they are worthy of your consideration.

To start with, PST Importer 2010 does not require Exchange Administrators to run complex scripts, nor do they have to open Port 135 on their firewalls. Instead, administrators must simply deploy an agent to the target machines, which facilitates the PST inventory and collection process.

Once the agents have been deployed, administrators can immediately begin searching computers for PST files. The process for doing so is simple, and merely involves selecting check boxes corresponding to the computers that need to be inventoried. Once the computers to be inventoried have been selected, the next step is to schedule the PST search , which will allow the PST information to be collected at a time when it will not interfere with user productivity.

Identifying Who the PST Files Belong To

Of course, locating the PST files that exist on the computers in your organization is only the first step in the process. The next step involves trying to identify which PST files belongs to which users. The scripts that I discussed earlier are designed to make note of each PST file’s owner and the file’s location (which will also usually reference the owner), and while this information should provide a reliable method of identifying who each PST file belongs to, it is ultimately up to the administrator to confirm each PST file’s owner.

PST Importer 2010 uses similar information to determine the owner of each PST file, but it does so automatically, and so the administrator is saved from the task of manually verifying each PST file’s owner.

Before you actually begin importing PST data, I recommend that you take some time to educate the users about what you are doing. Otherwise, you can be sure that your helpdesk will receive lots of calls from confused users after the PST files have been imported.

Importing PST Data

The next step is the actual import process. Those of you who are performing the import without the aid of third party software can accomplish the task through the use of Exchange Management Shell commands or PowerShell scripts. However, if you’re not so confident in your scripting skills, or if you just don’t want the hassle, then the import process is a lot simpler with PST Importer 2010, because no command line interaction is required.

Before you can perform the import process using PST Importer 2010, you must determine what types of PST data you want to import into Exchange Server; the PST Importer will always import mail items, but you must decide if you want to import calendar items as well. The tool also contains an option for importing non-mail items such as contacts, tasks, and notes.

Once the PST files on your network have been discovered, the PST Importer uses the associated profile information to determine which Exchange Server mailbox to import each PST file into. The import process itself is performed automatically, and in a way that preserves any folder structures that were set up within the PST file (). You can import the PST items to either the user’s primary Inbox folder, or you can place the imported items into a newly created subfolder as a way of keeping the items isolated from any data that already exists in the user’s Inbox.

The Aftermath

Regardless of whether you use EMS commands or a tool such as PST importer, you are likely to discover that some PST files were not imported successfully. There are several different factors that can cause this.

To troubleshoot these failed imports, start by making sure that the computer containing the PST files was turned on when the import was attempted. If the computer is (or was) off, then the PST file will obviously have been inaccessible.

Another thing to check is that the user who owns the PST file did not have Outlook open at the time of the import, because if Outlook was open (and it had the PST file held open) then the import process will have failed.

You should also talk to the user and verify that the PST file is not password protected. If you find that a PST file is password protected and you cannot get the password then, as mentioned earlier (admittedly in a slightly different context), there are a number of cracking utilities freely available on the Internet.

Finally, it could be that the import failed because the PST file itself was corrupt. You can use the Inbox Repair Tool or any of the third party PST repair tools to try to correct the problem, but you should back up the PST file before you do so, as using these tools can lead to data loss.

Conclusion

As you can see, PST data can be imported into Exchange Server 2010 either manually, or through the use of third party utilities such as PST Importer 2010. Either method will work, and both share a few challenges (although these are more a result of working with PST files than the methods themselves). However, the PST Importer 2010 makes the process of locating, identifying, and importing PST data much easier.

This article was commissioned by Red Gate Software, engineers of ingeniously simple tools for optimizing your Exchange email environment. To download your 14 day free trial of the PST Importer 2010 visit the Red Gate site.

http://www.simple-talk.com/sysadmin/exchange/importing-pst-file-data-into-exchange-server/

Today my boss ask me to inventory all the unix server (all serial numbers).

I know there’s a cool utility for Solaris that can retreive the Chasis Serial Number (CSN) or the Product Serial Number (PSN), but Sneep is not installed by default in Solaris, especially Solaris 8 (the old servers).

http://www.sunsolarisadmin.com/hardware/find-chasis-serial-number-using-sneep/

Go … Virtual …

————————————-
Microsoft Visual C++ Runtime Library

Runtime Error!

Program: c:Program FilesInternet Exploreriexplorer.exe

This application has requested the Runtime to terminate it in an unusual way. Please contact the application’s support team for more information.
——————————————–

I’ve already remove all the Java Apps and reinstall Internet Explorer, but still … with a whole day browsing …. finally it can get cured with Ad-Aware

Article ID : 871122
Last Review : October 6, 2005
Revision : 2.2
INTRODUCTION
The Wireless Network Setup Wizard and the View Available Wireless Networks feature both rely on the Wireless Zero Configuration service to provide their functionality to Microsoft Windows XP Service Pack 2 (SP2) and Microsoft Windows XP Table PC Edition 2005. If the Wireless Zero Configuration service is not available, you receive an error message that directs you to this article.
Back to the top

MORE INFORMATION
This behavior occurs for several reasons. Some computer and hardware manufacturers provide their own configuration software that replaces the Wireless Zero Configuration service that is provided in Windows. In that case, you must use the software that is provided by the manufacturer to configure your wireless network. If you want to use the Wireless Network Setup Wizard or the View Available Wireless Networks feature to configure your wireless device, see the documentation that came with your computer or with your wireless network card. Use this documentation to determine whether you can use the Wireless Zero Configuration service to configure your wireless network. Sometimes, you cannot use the Windows functionality.

If your computer or your wireless network adapter did not come with its own wireless network software, follow these steps: 1. Click Start, click Run, type ncpa.cpl, and then click OK.
2. Click Network Connections. 
3. In Network Connections, click to select your wireless connection, and then click Change settings of this connection. 
4. On the Wireless Networks tab, click to select the Use Windows to configure my wireless network settings check box.

To start the Wireless Zero Configuration service, follow these steps: 1. Click Start, click Run, type %SystemRoot%\system32\services.msc /s, and then click OK.
2. Double-click Wireless Zero Configuration. 
3. In the Startup type list, click Automatic, and then click Apply. 
4. In the Service status area, click Start, and then click OK.