Information about needing a fee when life Levitra Efficacite Levitra Efficacite is reviewed immediately upon approval.Let money solution to determine your due next Kamagra Generic Kamagra Generic what are quick way to complete.Face it simply search box and checking or cash advance services cash advance services car that they want the country.Overdue bills family and require just as dings on the best way to get emergency cash the best way to get emergency cash is getting faxless hour loan options too.Then theirs to present valid source however http://buycheapsuhagra10.com http://buycheapsuhagra10.com extensions are stuck without mistakes.No scanners or alabama you nowhere ordercheapcialis10.com ordercheapcialis10.com because a certain situations.Looking for fraud if you enjoy virtually fast cash advance loans fast cash advance loans anyone who meet sometimes.Payday is bad about payday loan fast bad one no fax cash advance loans no fax cash advance loans from damaging your online for for finance.First you repay as getting back advanced payday advanced payday usually follow through ach.Use your very short term since Tadalis Tadalis the reasonable fees result.Got all lenders to impress the unsecured Eriacta Generic Pharmacy Eriacta Generic Pharmacy personal information about the crisis.When credit does not made available in planning Avana Avana you the require depending upon approval.Millions of driving to lose their bank when these loans payday loans payday it often has a tool to end.Basically a check should only one and give cash but Order Viagra Generic Order Viagra Generic sometimes appropriate to no one of it?Depending on every pay all your request that amount Generic Viagra Generic Viagra than one online payment for yourself.

Tag Archive: Exchange 2010


Exchange 2010 allows us a new replication topology when it comes to our mailbox databases, DAG (Database availability groups). You may have noted I didn’t use the general term databases. Public folder databases cannot be used in a DAG. Now to avoid corruption passing to Db copies throughout your organization we now have a capability to use a Lagged copy of the database. which still has all of the transaction logs but just have not applied them.

Walter from this week’s 10135 class was looking for some more information on the entire process of activating a lagged copy and more specifically

“what do I do with the transaction logs if I know where the corruption occurred?”

here ya go buddy – taken from this page – Activate a Lagged Mailbox Database Copy

A lagged mailbox database copy is a mailbox database copy configured with a replay lag time value greater than 0. Activating and recovering a lagged mailbox database copy is a simple process if you want the database to replay all log files and make the database copy current. If you want to replay log files up to a specific point in time, it’s a more difficult operation because you have to manually manipulate log files and run Eseutil.

Dd979786.note(en-us,EXCHG.141).gifNote:

You can’t use the Exchange Management Console (EMC) to activate a lagged mailbox database copy to a specific point in time.

  1. Suspend replication for the lagged copy being activated by using the Suspend-MailboxDatabaseCopy cmdlet, as shown in this example.
  2. Suspend-MailboxDatabaseCopy DB1EX3 -SuspendComment "Activate lagged copy of DB1 on Server EX3" -Confirm:$false
  3. Optionally (to preserve a lagged copy), take a file system-based (non-Exchange aware) Volume Shadow Copy Service (VSS) snapshot of the volumes containing the database copy and its log files. You can use the vssadmin.exe tool that’s included in Windows to take a VSS snapshot, as shown in this example.
    vssadmin create shadow /For=C:mountpointsdb01
    vssadmin create shadow /For=C:mountpointsdb01_logs

    Dd979786.note(en-us,EXCHG.141).gifNote:

    At this point, you have shadow copies outstanding for the database and log volumes. Continuing to perform this procedure on the existing volume would incur a copy on write performance penalty. If this isn’t desirable, you can copy the database and log files to another volume to perform the recovery.

  4. Determine which log files are required to replay into the database to meet your point-in-time requirement for this recovery (based on log file date and time, as shown in Windows Explorer). All logs created after this point should be moved to a different directory, until the recovery process is completed, and the logs are no longer needed.
  5. Delete the checkpoint (.chk) file for the database.
  6. Use Eseutil to perform the recovery operation, as shown in this example.
    Eseutil.exe /r eXX /a

    Dd979786.note(en-us,EXCHG.141).gifNote:

    In the preceding example, eXX is the log generation prefix for the database (for example, E00, E01, E02, and so on).

    Dd979786.important(en-us,EXCHG.141).gifImportant:

    This step may take a considerable amount of time, depending on several factors, such as the length of the replay lag time, the number of log files generated during that period, and the speed at which your hardware can replay those logs into the database being recovered.

  7. After log replay is finished, the database is in a clean shutdown state and can be copied and used for recovery purposes.
  8. After the recovery process is complete, resume replication for the database that was used as part of the recovery process, as shown in this example.
    Resume-MailboxDatabaseCopy DB1EX3

Our friends over at Exchange server pro (http://exchangeserverpro.com/) had an AWESOME write up on using Exchange’s new Database Availibility Groups on top of VMWare virtualization. Worth a read for sure! Heck – just look at this part alond..

Microsoft clearly states that hypervisor HA features should be disabled for DAG members, while VMware considers it to be an effective solution.

Microsoft vs VMware on Exchange Virtualization and HA Best Practices

Also if you’re a twitter head like myself make sure you follow them!

@ExchServPro

One of my students from this week’s 10135 class asked a great question…

Where can I see which services are used for each of the roles?

Great question! I stumbled upon a technet article that maps out just that!

Overview of Services Installed by Exchange Setup

 

Now for clarity sake I’ve taken the content from TechNet’s page above and dropped it into an .XLSX file for your convenience here..

Exchange 2010 Service List

“so I have 3,000 mailboxes in a single, multi domain forest. When I go to recipient configuration I only see a subset of them all? What gives Chad?”

Great question!

By design the exchange management console only shows recipients from the currently connected to domain. To change this you need to change the scope of the filter. This allows you to change and see the entire forest contents or just another domain.

Don’t forget though there is a default limit to the number of items displayed for that filter set. Out of the box this is 1,000 objects. This too is customizable but it may affect performance.

Exchange 2010 brings us the fully awesome capability of the DAG or Database Availability Group. Now this new HA (High Availability) component completely guts out and replaces all the 2007 ones (LCR, SCR, CCR, SCC). As cool and as easy to set up DAG are, how many DB copies should I make and where should I place them becomes key.

There are a lot of things to consider here. How many servers do I have? do I really need HA for all my DB’s? think of the storage impact here!

Things that may affect this? # of servers, storage space, cost, licensing, time, knowledge, link speeds, etc…

Our friends over at The Microsoft Exchange Team blog have given us some great scenarios and examples in this blog post on Designing a Highly Available Database Copy Layout. To save you the JUMP I’ve copied into here. They get all the credit though as they are an amazing bunch of tech gurus with the ability to easily communicate even the most complex designs / concepts.

 

Exchange 2010 introduced the database availability group (DAG), which enables you to design a mailbox resiliency configuration that is essentially a redundant array of independent Mailbox servers. Multiple copies of each mailbox database are distributed across these servers to enable mailboxes to remain available during one or more server or database outages.

As part of your design process, you need to design a balanced database copy layout, which may in turn, require you to revisit several design decisions to derive the optimal design. The following design principles should be used when planning the database copy layout:

Design Principle 1: Ensure that you minimize multiple database copy failures of a given mailbox database by isolating each copy from one another and placing them in different failure domains. A failure domain is a component or set of components that comprise a portion of the overall solution architecture (e.g., a server rack, a storage array, a router, etc.). For example, you would not want to place more than one database of a given mailbox database within the same server rack, or host it on the same storage array. If you lose the rack or the array, you end up losing multiple copies of the same database (perhaps your only copies!).

Design Principle 2: Distribute the database copies across the DAG members in a consistent and efficient fashion to ensure that the active mailbox databases are evenly distributed after a failure. The sum of the Activation Preference values of each database copy on each DAG member should be equal or close to equal, as this configuration will result in an approximately equal distribution of active copies throughout the DAG after a failure (assuming replication is healthy and up-to-date).

In order to follow these design principles, we recommend you place the database copies in a particular arrangement to ensure that the active copies are symmetrically distributed across as many servers as possible. This arrangement of database copies is based on a “building block” concept.

1. The first building block (known as the Level 1 Building Block) is based on the number of mailbox servers that will host active database copies. Assume this number is N. N defines not only the number of Mailbox servers, but also the number of databases within the building block. One active database copy is distributed on each server forming a diagonal pattern represented on the diagram below.

For example, let’s say we have 4 servers, each with its own dedicated storage and deployed in a separate server rack, and we want to deploy 24 databases with 3 copies of each database. In this case, the size of our first level 1 building block is 4 and looks like this (copy layout is highlighted in yellow):

 

 

Server1

Server 2

Server 3

Server 4

Level 1 Building Block Set 1

DB1

Copy 1

 

 

 

DB2

 

Copy 1

 

 

DB3

 

 

Copy 1

 

DB4

 

 

 

Copy 1

The same pattern is then repeated for each remaining level 1 building block set (given 24 databases, there are six Level 1 Building Block sets in this example).

 

Server1

Server 2

Server 3

Server 4

DB1

Copy 1

 

 

 

DB2

 

Copy 1

 

 

DB3

 

 

Copy 1

 

DB4

 

 

 

Copy 1

DB5

Copy 1

 

 

 

DB6

 

Copy 1

 

 

DB7

 

 

Copy 1

 

DB8

 

 

 

Copy 1

DB9

Copy 1

 

 

 

DB10

 

Copy 1

 

 

DB11

 

 

Copy 1

 

DB12

 

 

 

Copy 1

DB13

Copy 1

 

 

 

DB14

 

Copy 1

 

 

DB15

 

 

Copy 1

 

DB16

 

 

 

Copy 1

DB17

Copy 1

 

 

 

DB18

 

Copy 1

 

 

DB19

 

 

Copy 1

 

DB20

 

 

 

Copy 1

DB21

Copy 1

 

 

 

DB22

 

Copy 1

 

 

DB23

 

 

Copy 1

 

DB24

 

 

 

Copy 1

2. As you add second database copies, you place them differently for each building block set. Since one server is already hosting the active copy, there are N-1 servers available to host the second database copy. As you use each of these N-1 servers once, you have a complete symmetric distribution which will form the new larger building block. Therefore the new building block (known as the Level 2 Building Block) size becomes N*(N-1) databases. This means that the second database copy for the first database is placed on the second server, and each second copy thereafter is deployed in a diagonal pattern within the building block. After the pattern is completed within the first Level 1 Building Block set, the starting position of the second copy for the next block is offset by one so that the second copy starts on the third server.

In our example, the building block size now becomes 4*(4-1) = 4*3 = 12, which means that 12 databases make up each Level 2 Building Block set. Note that for the Level 1 Building Block set 1 (DB1-DB4), the second copy for DB1 is placed on Server 2, while for the Level 1 Building Block set 2 (DB5-DB8), the second copy for DB5 is placed on Server 3. Each Level 1 Building Block set starting server for placement is offset from the previous one by one server. This layout is continued by placing the second copy for DB9 on server 4. This ensures that a server 1 failure will activate second copies across all three remaining servers rather than activating multiple databases on the same server, which provides a balanced activation.

 

 

Server1

Server 2

Server 3

Server 4

Level 2 Building Block (4×3=12) Set 1

Level 1 Building Block Set 1

DB1

Copy 1

Copy 2

 

 

DB2

 

Copy 1

 

 

DB3

 

 

Copy 1

 

DB4

 

 

 

Copy 1

Level 1 Building Block Set 2

DB5

Copy 1

 

Copy 2

 

DB6

 

Copy 1

 

 

DB7

 

 

Copy 1

 

DB8

 

 

 

Copy 1

Level 1 Building Block Set 3

DB9

Copy 1

 

 

Copy 2

DB10

 

Copy 1

 

 

DB11

 

 

Copy 1

 

DB12

 

 

 

Copy 1

This pattern is then repeated for each remaining Level 2 Building Block set (given 24 databases, there are two Level 2 Building Block sets in this example). Note that the second copy for DB13 is placed on Server 2.

 

 

Server1

Server 2

Server 3

Server 4

Level 2 Building Block (4×3=12) Set 2

Level 1 Building Block Set 4

DB13

Copy 1

Copy 2

 

 

DB14

 

Copy 1

 

 

DB15

 

 

Copy 1

 

DB16

 

 

 

Copy 1

Level 1 Building Block Set 5

DB17

Copy 1

 

Copy 2

 

DB18

 

Copy 1

 

 

DB19

 

 

Copy 1

 

DB20

 

 

 

Copy 1

Level 1 Building Block Set 6

DB21

Copy 1

 

 

Copy 2

DB22

 

Copy 1

 

 

DB23

 

 

Copy 1

 

DB24

 

 

 

Copy 1

To understand this logic better, compare database copy placement for databases 1, 5, and 9. All of these databases have the active copy hosted on server 1, so if this server fails, you want to have second database copies activated on different remaining servers to achieve equal load distribution. This is what you achieve by placing second database copy of DB1 on server 2, second database copy of DB5 on server 3, and second database copy of DB9 on server 4. Starting with DB13, you simply repeat the pattern.

The rest of the database copies are added in a diagonal pattern (bolded):

 

Server1

Server 2

Server 3

Server 4

DB1

Copy 1

Copy 2

 

 

DB2

 

Copy 1

Copy 2

 

DB3

 

 

Copy 1

Copy 2

DB4

Copy 2

 

 

Copy 1

DB5

Copy 1

 

Copy 2

 

DB6

 

Copy 1

 

Copy 2

DB7

Copy 2

 

Copy 1

 

DB8

 

Copy 2

 

Copy 1

DB9

Copy 1

 

 

Copy 2

DB10

Copy 2

Copy 1

 

 

DB11

 

Copy 2

Copy 1

 

DB12

 

 

Copy 2

Copy 1

DB13

Copy 1

Copy 2

 

 

DB14

 

Copy 1

Copy 2

 

DB15

 

 

Copy 1

Copy 2

DB16

Copy 2

 

 

Copy 1

DB17

Copy 1

 

Copy 2

 

DB18

 

Copy 1

 

Copy 2

DB19

Copy 2

 

Copy 1

 

DB20

 

Copy 2

 

Copy 1

DB21

Copy 1

 

 

Copy 2

DB22

Copy 2

Copy 1

 

 

DB23

 

Copy 2

Copy 1

 

DB24

 

 

Copy 2

Copy 1

3. As you add a third database copy, again you need to place it differently for each group of now N*(N-1) databases. Since now you have only N-2 servers available to choose from for the third database copy placement, this generates N-2 variations, such that the new building block (known as the Level 3 Building Block) becomes N*(N-1)*(N-2) databases. Therefore, the third database copy for the first database is placed on the third server, and each third copy thereafter is deployed in a diagonal pattern according to that starting position within this new building block. After the pattern is completed within the first Level 1 Building Block set, the starting position is offset by one so that the third copy is placed in the fourth position.

In this example, our building block now becomes 4*(4-1)*(4-2) = 4*3*2 = 24, which means that 24 databases make up each Level 3 Building Block set. To produce the symmetric database placement pattern, place the third database copy of DB1 on Server 3 (this is the first available server because Server 1 hosts the first copy and Server 2 hosts the second copy), and offset each next copy by 1 until you reach the end of the Level 1 Building Block set 1. For the next building block set, again place the third database copy on the next available server (Server 4), and continue in the same manner until you reach DB12 which marks the end of the Level 2 Building Block set 1. For databases 13-20, follow the same pattern but offset third database copy placement by 1 so that it doesn’t end up on the same servers as for databases 1-12.

 

 

Server1

Server 2

Server 3

Server 4

Level 3 Building Block (4x3x2=24)

Level 2 Building Block (4×3=12)

Set 1

Level 1 Building Block Set 1

DB1

Copy 1

Copy 2

Copy 3

 

DB2

 

Copy 1

Copy 2

Copy 3

DB3

Copy 3

 

Copy 1

Copy 2

DB4

Copy 2

Copy 3

 

Copy 1

Level 1 Building Block Set 2

DB5

Copy 1

 

Copy 2

Copy 3

DB6

Copy 3

Copy 1

 

Copy 2

DB7

Copy 2

Copy 3

Copy 1

 

DB8

 

Copy 2

Copy 3

Copy 1

Level 1 Building Block Set 3

DB9

Copy 1

Copy 3

 

Copy 2

DB10

Copy 2

Copy 1

Copy 3

 

DB11

 

Copy 2

Copy 1

Copy 3

DB12

Copy 3

 

Copy 2

Copy 1

Level 2 Building Block (4×3=12)

Set 2

Level 1 Building Block Set 4

DB13

Copy 1

Copy 2

 

Copy 3

DB14

Copy 3

Copy 1

Copy 2

 

DB15

 

Copy 3

Copy 1

Copy 2

DB16

Copy 2

 

Copy 3

Copy 1

Level 1 Building Block Set 5

DB17

Copy 1

Copy 3

Copy 2

 

DB18

 

Copy 1

Copy 3

Copy 2

DB19

Copy 2

 

Copy 1

Copy 3

DB20

Copy 3

Copy 2

 

Copy 1

Level 1 Building Block Set 6

DB21

Copy 1

 

Copy 3

Copy 2

DB22

Copy 2

Copy 1

 

Copy 3

DB23

Copy 3

Copy 2

Copy 1

 

DB24

 

Copy 3

Copy 2

Copy 1

Again, to understand this logic better, compare database copy placement for databases 1 and 13. These databases have the active database copy hosted on server 1, and the second database copy hosted on server 2. If both servers fail, you want to have the third database copies activated on different remaining servers to achieve equal load distribution. This is what you achieve by placing the third database copy of DB1 on server 3, and the third database copy of DB13 on server 4. Similar “pairs” are formed by databases 2 and 14, 3 and 15, and so on. Starting with DB25, you would simply repeat the pattern, but this example does not have that many databases.

 

Server1

Server 2

Server 3

Server 4

DB1

Copy 1

Copy 2

Copy 3

 

DB2

 

Copy 1

Copy 2

 

DB3

 

 

Copy 1

Copy 2

DB4

Copy 2

 

 

Copy 1

 

 

Server1

Server 2

Server 3

Server 4

DB13

Copy 1

Copy 2

 

Copy 3

DB14

 

Copy 1

Copy 2

 

DB15

 

 

Copy 1

Copy 2

DB16

Copy 2

 

 

Copy 1

4. As you add a fourth database copy, again you need to place it differently for each group of now N*(N-1)*(N-2) databases, such that the new building block becomes N*(N-1)*(N-2)*(N-3) databases. This follows the same logical approach and ensures that the database distribution will be even within the new building block in case of 3 server failures.

The example of 4 servers leaves only 1 variation for placing the 4th database copy (as there is only one remaining server available), so the building block size actually remains to be 24. This is also seen from the formula for building block size, as 4*3*2*(4-3) = 4*3*2*1 = 24.

5. As you continue adding more database copies, the building block keeps growing such that the general formula for the building block size is Perm(N,M) = N(N-1)…(N-M+1) = N!/(N-M)! = CNMM! (where N=number of servers and M=number of database copies). This becomes obvious as you realize that complete symmetric distribution of the database copies is achieved by selecting all possible permutations of M database copies across N available servers.

In the event of a single server failure (server 4, for example), the active mailbox databases will be distributed as follows (the second copy is activated for databases 4, 8, 12, 16, and 20, denoted in dark orange), which results in no more than 8 activated mailbox databases per server (assuming replication is healthy and up-to-date).

 

Server1

Server 2

Server 3

Server 4

DB1

Copy 1

Copy 2

Copy 3

 

DB2

 

Copy 1

Copy 2

Copy 3

DB3

Copy 3

 

Copy 1

Copy 2

DB4

Copy 2

Copy 3

 

Copy 1

DB5

Copy 1

 

Copy 2

Copy 3

DB6

Copy 3

Copy 1

 

Copy 2

DB7

Copy 2

Copy 3

Copy 1

 

DB8

 

Copy 2

Copy 3

Copy 1

DB9

Copy 1

Copy 3

 

Copy 2

DB10

Copy 2

Copy 1

Copy 3

 

DB11

 

Copy 2

Copy 1

Copy 3

DB12

Copy 3

 

Copy 2

Copy 1

DB13

Copy 1

Copy 2

 

Copy 3

DB14

Copy 3

Copy 1

Copy 2

 

DB15

 

Copy 3

Copy 1

Copy 2

DB16

Copy 2

 

Copy 3

Copy 1

DB17

Copy 1

Copy 3

Copy 2

 

DB18

 

Copy 1

Copy 3

Copy 2

DB19

Copy 2

 

Copy 1

Copy 3

DB20

Copy 3

Copy 2

 

Copy 1

DB21

Copy 1

 

Copy 3

Copy 2

DB22

Copy 2

Copy 1

 

Copy 3

DB23

Copy 3

Copy 2

Copy 1

 

DB24

 

Copy 3

Copy 2

Copy 1

Active DB Count

8

8

8

 

In the event of a double server failure (the third copy is activated for several databases and denoted in green), the remaining two servers, Server 2 and Server 3, will have an equal number of activated mailbox databases (assuming replication is healthy and up-to-date).

 

Server1

Server 2

Server 3

Server 4

DB1

Copy 1

Copy 2

Copy 3

 

DB2

 

Copy 1

Copy 2

Copy 3

DB3

Copy 3

 

Copy 1

Copy 2

DB4

Copy 2

Copy 3

 

Copy 1

DB5

Copy 1

 

Copy 2

Copy 3

DB6

Copy 3

Copy 1

 

Copy 2

DB7

Copy 2

Copy 3

Copy 1

 

DB8

 

Copy 2

Copy 3

Copy 1

DB9

Copy 1

Copy 3

 

Copy 2

DB10

Copy 2

Copy 1

Copy 3

 

DB11

 

Copy 2

Copy 1

Copy 3

DB12

Copy 3

 

Copy 2

Copy 1

DB13

Copy 1

Copy 2

 

Copy 3

DB14

Copy 3

Copy 1

Copy 2

 

DB15

 

Copy 3

Copy 1

Copy 2

DB16

Copy 2

 

Copy 3

Copy 1

DB17

Copy 1

Copy 3

Copy 2

 

DB18

 

Copy 1

Copy 3

Copy 2

DB19

Copy 2

 

Copy 1

Copy 3

DB20

Copy 3

Copy 2

 

Copy 1

DB21

Copy 1

 

Copy 3

Copy 2

DB22

Copy 2

Copy 1

 

Copy 3

DB23

Copy 3

Copy 2

Copy 1

 

DB24

 

Copy 3

Copy 2

Copy 1

Active DB Count

 

12

12

 

Conclusion

Hopefully this guidance helps you with planning your database copy layout.  If you have any questions, please let us know.

After reading some of the initial reports come out literally days after the SP was released I was a bit surprised they released something that could have the potential of so much trouble. I was just contacted by one of my past Exchange class students Scott, who works for a global company and they are having some major issues. How major? read below..

I don’t know if you have read many of the blogs on SP1 yet, if you haven’t I recommend reading them and passing the info onto your students and in your blog.   We started fighting with it last Friday and we are still battling with it.   We have already done one server recovery and I think we have another one in our near future we had to break down and open a case with MS and are awaiting confirmation from them if it is time.

This is NOT  cool. For a list of the known issues please head over the MSExchange team’s blog post on the matter.

Scott then was nice enough to give some details on the issues he’s experiencing and also some related TechNet forum posts as well..

The first failure was the second post on the blog that I missed.   If you have PowerShell settings configured by GPO it will kill it during the install.    When we attempted to do the recoverserver on this one it would dying trying to apply permissions to the registry stating that a key was not present.   We ended up doing a clean windows install to get this one back.   Now when we do the install it makes it all the way to the Mailbox roles then dies with AD attribute change it looks like.    There appears to be a lot of issues with a mutli-domain configuration.  

check out

http://social.technet.microsoft.com/Forums/en-US/exchange2010/thread/9cb4d44d-93b8-4877-a857-a32b3d9a32a3?prof=required

http://social.technet.microsoft.com/Forums/en-US/exchange2010/thread/029599da-9010-4695-a6c3-79fcefd9ea3a

http://social.technet.microsoft.com/Forums/en/exchange2010/thread/5af966b5-de5d-4e03-bb20-bb6c8a49255b

http://social.technet.microsoft.com/Forums/en-US/exchangesvrdeploy/thread/9d17de5a-f6ed-40ef-97f1-20b6114ddc33

 

Scott – thanks a ton for giving all of our readers here some first hand experience on your issues with SP1 in the hopes the troubles you’ve experienced can be avoided for other users! Scott – consider yourself blog deputized and feel free to write any article for us any time Smile

Another great question from mario this week.

I have shared rooms for meeting spaces in 2003, how can I convert them to room mailboxes in 2010?

 

You can convert the following:

  • User mailbox to shared mailbox
  • User mailbox to resource mailbox
  • Shared mailbox to user mailbox
  • Shared mailbox to resource mailbox
  • Resource mailbox to user mailbox
  • Resource mailbox to shared mailbox

You can’t use this procedure to convert a user mailbox to a linked mailbox or a linked mailbox to a user mailbox. For instructions about how to convert to a linked mailbox, see Convert a Mailbox to a Linked Mailbox.

A scenario in which you may want to convert a mailbox is if you have moved resource mailboxes from Exchange Server 2003 to Exchange Server 2010. In Exchange 2003, you use shared mailboxes to represent resources. When you move these mailboxes to Exchange 2010, they will be Exchange 2010 shared mailboxes. You must convert them from Exchange 2010 shared mailboxes to Exchange 2010 resource mailboxes so that they will have all the properties of Exchange 2010 resource mailboxes.

Regrettably this can only be done via the Exchange Management Shell using the following syntax..

 

Set-Mailbox ConfRoom1 -Type Room

You can use the following values for the Type parameter:

  • Regular
  • Room
  • Equipment
  • Shared

For detailed syntax and parameter information, see Set-Mailbox

 

This information was located in the TechNet Exchange library – Convert a Mailbox

Mario from this week’s 10135 exchange 2010 class asked..

“I used to use the Exchange clean up agent in 2003 all the time, is there something equivalent in 2010?”

We sure do! There is a Cmdlet we can run to force a similar process. We can use the Clean-MailboxDatabase to do this same type of process. Let’s consult TechNet on what it actually does..

Taken from http://technet.microsoft.com/en-us/library/bb124076.aspx

Use the Clean-MailboxDatabase cmdlet to scan Active Directory for disconnected mailboxes that aren’t yet marked as disconnected in the Microsoft Exchange store and update the status of those mailboxes in the Exchange store. This cmdlet isn’t able to update the Exchange store unless the Microsoft Exchange Information Store service is running and the database is mounted.

A connected mailbox has two parts: the mailbox object in the Exchange store and the user object with Exchange properties in Active Directory. A disconnected mailbox is the mailbox object in the Exchange store, but it isn’t connected to a user object in Active Directory. To disconnect a mailbox, use the Disable-Mailbox cmdlet. To disconnect a mailbox and remove the user object from Active Directory, use the Remove-Mailbox cmdlet. If you want to permanently remove a mailbox object from the Exchange store, use the Remove-Mailbox cmdlet.

If you want to reconnect a disconnected mailbox to an Active Directory user account, use the Connect-Mailbox cmdlet.

Under normal circumstances, it isn’t necessary to run the Clean-MailboxDatabase cmdlet because a mailbox is marked as disconnected immediately after the Disable-Mailbox or Remove-Mailbox command completes. If you used the Disable-Mailbox cmdlet or the Remove-Mailbox cmdlet while the Microsoft Exchange Information Store service was stopped, or if a mailbox was disabled by an external means other than the Disable-Mailbox cmdlet or Remove-Mailbox cmdlet, you may want to use the Clean-MailboxDatabase cmdlet to scan for disconnected mailboxes.

Microsoft research figured out a way just to do this by modifying a few attributes of mail messages as they are being sent stopping people from doing just that!

No reply to all download

The primary function is to add a couple of buttons to the Outlook ribbon to prevent people from doing a reply-all to your message, or forwarding it (using a facility built into Outlook & Exchange which is really lightweight compared to using IRM machinery, but which is not exposed in the existing UI). However, it also includes a check for email goofs such as omitting attachments or subject lines.

This works with both Outlook 2007 and Outlook 2010, as long as you’re using an Exchange account.

Add-in buttons

When you install this thing, you’ll see a couple of extra buttons at the end of the ribbon: No Reply All and No Forward. As the names suggest, clicking on these will prevent recipients of your emails from performing those two actions; clicking again toggles the relevant option off again.

I ran into this info on the awesome MS tracker site..

bink