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.

Archive for October, 2010


,,

Well it appears that Lync 2010 (A.K.A. – new OCS product) has finally hit the RTM phase of it’s life cycle. I can’t wait to download the final bits and test it in a lab environment along side a Exchange 2010 server with Office 2010 clients!

What IS Lync anyway? The home Lync site describes it as..

  "Microsoft Lync Server 2010 delivers complete presence, instant
messaging, conferencing and enterprise voice capabilities through a
single, easy-to-use interface that is consistent across PC, browser, and
mobile device. Administrators benefit from a single, consistent
management infrastructure, new capabilities to increase availability,
and interoperability with existing systems"

The announcement and the prodcut is also descibed on the Microsoft Unified Communications team blog

Sound interested? enterprise VOIP / IM and more? Don’t want to pay for the infrasturcture to support it? Have you checked out the Office365 suite yet?

 


Microsoft has now published a list of OSDX connector files for some of the more popular sites they host and a few others. What is an OSDX file and why do I care? See my preivous post on OSDX connectors for Windows 7

 

good list for sites like..

Bing news

Bing Images

Bing local

YouTube

Yahoo

Yahoo News

Yahoo Images

VL Program guides

Wikipedia

Google blogs

Google News

Flikr

TechNet

MSDN

 

It’s all about being able to search more than just your local pc, all without even having to open up a browser! Our friends over at Bink put up a nice consolodated list of the connectors with links to each’s download page – Enjoy

 

Bink.Nu – MSFT releases search connectors

“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.

Bob had a great question when it came to published CRL’s vs Online responders.

“Why is one preferred, and when is one used over the other?”

To get to the bottom of this let’s see how the validation process works. SEE Certificate Revocation and Status Checking

Certificate Status Checking

When an application requests the certificate chaining engine to evaluate a certificate, the validation is performed on all certificates in that certificate’s chain. This includes every certificate from the leaf certificate presented to the application to the root certificate.

When the first certificate in the chain is validated, the following process takes place.

  1. The chaining engine will attempt to find the certificate of the CA that issued the certificate being examined. The chaining engine will inspect the local system certificate stores to find the parent CA certificate. The local system stores include the CA store, the Root store, and the Enterprise Trust store. If the parent CA certificate is not found in the local system certificate stores, the parent CA certificate is downloaded from one of the URLs available in the inspected certificates AIA extensions. The paths are built without signature validation at this time because the parent CA certificate is required to verify the signature on a certificate issued by the parent CA.

  2. For all chains that end in a trusted root, all certificates in the chain are validated. This involves the following steps.

    • Verify that each certificate’s signature is valid.

    • Verify that the current date and time fall within each certificate’s validity period.

    • Verify that each certificate is not corrupt or malformed.

  3. Each certificate in the certificate chain is checked for revocation status. The local cache is checked to see if a time valid version of the issuing CA’s base CRL is available in the cache. If the base CRL is not available in the local cache, or the version in the local cache has expired, the base CRL is downloaded from the URLs available in the CDP extension of the evaluated certificate. If available, it is confirmed that the certificate’s serial number is not included in the CA’s base CRL.

    When a root certificate—a certificate that contains the same DN for both the Subject and Issuer attributes—is encountered, a revocation check may or may not occur. If the certificate chaining engine behavior will depend on whether the application enables the CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT flag, which is the default, the root CA’s certificate is not checked for revocation. If the flag is not enabled, the root CA certificate is checked for revocation if the root CA certificate includes the CDP extension. If the CDP extension is not included, no revocation check is performed.

    Note  Windows XP RTM and Windows XP SP1 will perform revocation checking as the chain is built, rather than only performing revocation checking on chains that end at a trusted root CA.

  4. If the base CRL contains the Freshest CRL extension, the local cache is checked to see if a time valid version of the issuing CA’s delta CRL is available in the cache. If available, it is confirmed that the certificate’s serial number is not included in the CA’s delta CRL. If the delta CRL is not available in the local cache, or the version in the local cache has expired, the delta CRL is downloaded from the URLs available in the CDP extension of the evaluated certificate.

    Warning  If delta CRLs are enabled at a CA, both the base CRL and delta CRL must be inspected to determine the certificate’s revocation status. If one of the two, or both, are unavailable, the chaining engine will report that revocation status cannot be determined, and an application may reject the certificate.

Once the validation check is completed, the certificate chaining engine returns the results of the validation check to the calling application. The results will indicate if all certificates in the chain are valid, if the chain terminates at a non-trusted root CA, if any certificates in the chain are not valid, or if the revocation status for any of the certificates in the chain cannot be determined.

Note  If any certificate in the chain cannot be validated or is found to be revoked, the entire chain takes on the status of that one certificate.

 

Ok, now that we’ve got the validation part down. Let’s take a peek at Online Responders. What do they do differently than the CA and published CRL’s?

An Online Responder is a trusted server that receives and responds to individual client requests for information about the status of a certificate.

The use of Online Responders is one of two common methods for conveying information about the validity of certificates. Unlike certificate revocation lists (CRLs), which are distributed periodically and contain information about all certificates that have been revoked or suspended, an Online Responder receives and responds only to individual requests from clients for information about the status of a certificate. The amount of data retrieved per request remains constant no matter how many revoked certificates there might be.

In many circumstances, Online Responders can process certificate status requests more efficiently than by using CRLs. For example:

  • Clients who connect to the network remotely and either do not need nor have the high-speed connections required to download large CRLs.
  • A network needs to handle large peaks in revocation checking activity, such as when large numbers of users log on or send signed e-mail simultaneously.
  • An organization needs an efficient means to distribute revocation data for certificates issued from a non-Microsoft certification authority (CA).
  • An organization wants to provide only the revocation checking data needed to verify individual certificate status requests, rather than make available information about all revoked or suspended certificates.

Now the application has to be configured to use an Online responder. it’s not going to just figure it out on it’s own.

Bob from this week’s 6426 class posed the following question. I have some users who access multiple SQL databases, can ILM or FIM automate password changes across them?

I grabbed the information from the Understanding Forefront Identity Manager 2010 white paper which is accessible via the link. Here are a few choice excerpts

  • Heterogeneous identity synchronization & consistency. FIM 2010 delivers integration with a broad range of network operating systems, e-mail, database, directory, application, and flat-file access. FIM 2010 supports connectors for Active Directory, Novell, Sun, IBM, Lotus Notes, Microsoft Exchange Server, Oracle databases, Microsoft SQL Server™ databases, SAP and others. This provides organizations with the power to connect and synchronize the plethora of disparate sources of identity information in their company—in most cases without the need to install software of any kind on the target systems. Since in some cases it might be necessary to connect to custom or legacy applications unique to a specific organization, FIM 2010 extensible agent capabilities enables companies to integrate and manage identities for these applications through developing custom agents in the Microsoft Visual Studio® development environments.

 

  • Simplified sign-on by synchronizing passwords across systems. Importantly, FIM 2010 provides a simplified sign-on experience through its identity synchronization capabilities, delivering the ability to synchronize passwords across heterogeneous systems.

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