Mirroring TFS – Consider Index Rebuilds When Using TLog Backups

Mirroring a TFS DT is a very common action within large environments for a variety of reasons, redundancy and failover obviously being the primary catalysts for such an implementation but there are also a variety of other reasons why this is a beneficial action.

At a current client of mine where I was setting up initial, trial mirroring for the TFS instance, it because evident that the TfsIntegration Maintenance Job was causing issues with a long completion time which eventually resulted in TFS to respond uncharacteristically slow. Now this job does two things, firstly it re-indexes the TFS databases (TFSIntegration, TfsWarehouse, TfsWarehouse, TfsWorkItemTracking and TfsVersionControl) by calling the Re-indexing:TfsIntegration stored procedure. This is done by calling exec TfsIntegration.dbo.Prc_OptimizeTfsDatabases. As well, it also removes deleted process templates by calling exec TfsIntegration.dbo.prc_deleteTemplates. The first of these is the culprit though for this issue, and if you run the stored procedures directly you will see a Stop Request being issued which will result in the re-index has not being executed.

9 times out of the ten, because Index rebuilds and Defragmentation generate very hefty transaction logs, it is because a transaction log backup job (TLog backup job) is running while the re-indexing is executed. While calling TLog may help in log file reduction, it can also cause these issues when executed simultaneously with the index rebuild.


SharePoint Claims Based Authentication Architectures Explained Part 5 SharePoint Identity Across Realms

We have already talked about claims based identity and how to design a claims based application where the issuer is able to authenticate the users directly. You can actually take all of this one step further though. The process allows you to expand the capabilities of your issuer to accept a security token from another issuer. This means the user won’t have to directly authenticate it. Now the issuer is able to issue security tokens and to accept them from other issuers that it trusts.

As a result you will be able to have identity with other realms in spite of the fact that they are separate domains of security. This is a powerful ability that offers plenty of benefits. The process is accomplished by using the IT staff. They get to determine how issuers are going to be configured. You do need to understand these possibilities because they are the entry way to even more features for your application. You won’t have to change your application in any way though. Some of the different possibilities can offer some flexibility for your application design too.

Being able to maintain an identity database doesn’t have to be a difficult task. You can have a simple database that keeps the usernames and passwords that you need to manage in place. However, it is common for users to forget such information frequently. Chances are you have a high level of security in place for your business. Therefore it isn’t acceptable for you to just email those individuals new passwords.

It is very difficult to successfully manage a database for remote users. Lets say that you work for a partner company with a purchasing application. An IT staff make changes to your account as you work in the purchasing department. The IT staff gives you the role of purchaser so you are given permission to use the application. How are people with a different company going to learn about you being transferred to the sales department? What happens if you decide to quit your job for the company?

The changes will need to be found out, but don’t count on the human resources department to send out any type of notification. It should be something that the company you were employed with would need to manage. Storing information for remote users is often looked upon as a liability so keep that in mind. Any data that you store about remote users could turn out to be a liability for your business.

Over the course of time the data stored with a remote user will become old. There are some safe ways that you can expose applications so that a partner business will be able to use them. One of these methods involves decentralizing the process. You won’t have an issuer that authenticates remote users directly. Instead you will set up a trust relationship with an issuer that is part of another company.

Your issuer trusts their issuer to authenticate the users that are in the realm. These employees are satisfied because they don’t need any type of special credentials in order to be able to use your application. They will use the same single sign on ability that they used in their own company. Your application will work for them due to the came pass to get in. The claims you have to get the boarding pass for the remote users will be less powerful though because they aren’t really employees of your company.

It will be the responsibility of your issuer to determine those assignments. Your application won’t need to change either when new organizations are added as partners. This is a huge benefit of using claims because it allows your configuration of only one issuer to be accessed by so many new users out there.

It is possible to use claims to decentralize identity. This is going to eliminate data from becoming stale for remote users. Another benefit is that the claims will allow you to logically be able to store data about your users. The data can be stored with authority and be convenient to access and to use. Through the use of federation, many of the road blocks out there are removed so that new users can come in.

Your company will need to decide which realms to allow access to your claims based application. Your IT staff will be able to set up the relationships that need to be in place for them. They can get employees in a business that use Java to access your application but they won’t need to issue new passwords. They will only need to have a Java based issuer. Also, anyone with a Windows Live ID would be able to use your application.