How to Configure Generic SQL Server Linked Server Names
Problem
Every DBA is faced with the task of occasionally refreshing their databases from Staging to QA to Development. A while back I started working on a project where we were building out a new environment and our DBA team was frequently tasked with refreshing the new environment with data from the existing one. In this environment there were quite a few linked servers and every time we would restore a database to the new environment testers would start to get errors similar to the following:
Msg 7202, Level 11, State 2, Line 1 Could not find server 'STAGING_CRMDBSERVER' in sys.servers. Verify that the correct server name was specified. If necessary, execute the stored procedure sp_addlinkedserver to add the server to sys.servers. Msg 4413, Level 16, State 1, Line 1 Could not use view or function 'AllContacts' because of binding errors.
Solution
Initial solution to find and replace SQL Server Linked Servers
On the surface this is a pretty simple issue to fix. First thing I would do is search all of my stored procedures, functions, views and triggers for the linked server listed in the error using the following TSQL:
SELECT name,type_desc
FROM sys.objects
WHERE OBJECT_DEFINITION(object_id) LIKE '%LINKEDSERVER%'
AND type IN ('FN','IF','TF','V','P','TR')
Related Tips:
After I had found all the objects, assuming that the corresponding linked server is already created in the new environment, you can script the update of all the objects to use this linked server as follows:
SELECT name,type_desc,
OBJECT_DEFINITION(object_id) AS oldcode,
REPLACE(OBJECT_DEFINITION(object_id),'[LINKEDSERVER]','[NEWLINKEDSERVER]') AS newcode
FROM sys.objects
WHERE object_definition(object_id) LIKE '%LINKEDSERVER%'
AND type IN ('FN','IF','TF','V','P','TR')
Now, if your environment is fairly stagnant and you aren’t refreshing databases very often, the above process is a good solution, but during this project we were refreshing one database or another daily. Also factor into the equation that we couldn’t just script all the objects one time and reuse the script since our current environment was still being updated by developers. This meant we had to complete this entire process for every restore which became quite time consuming.
Final solution to address SQL Server Linked Server in Multiple Environments
The final solution I came up with was to recreate all the linked servers in our current environment using generic names. After that I created linked servers in the new environment with the same generic names pointing to the correct server in the new environment. Now my linked server names are standardized across my entire environment so I can restore any database to/from any environment without the need to update any of my database objects. You can create a linked server with a generic name using SQL Server Managment Studio as follows:
Note: You have to put single quotes in the product name text box otherwise you will get an error saying this value can not be NULL.
You can also create a generic linked server using TSQL with the following:
EXEC master.dbo.sp_addlinkedserver @server = N'GenericLinkedServer',
@provider=N'SQLNCLI10',
@datasrc=N'SQLSERVERNAME\INSTANCENAME',
@srvproduct=''
GO
EXEC master.dbo.sp_addlinkedsrvlogin @rmtsrvname=N'GenericLinkedServer',
@useself=N'False',
@locallogin=NULL,
@rmtuser='Username',
@rmtpassword='Password'
GO
EXEC master.dbo.sp_serveroption @server=N'GenericLinkedServer',
@optname=N'collation compatible',
@optvalue=N'false'
GO
EXEC master.dbo.sp_serveroption @server=N'GenericLinkedServer',
@optname=N'data access',
@optvalue=N'true'
GO
EXEC master.dbo.sp_serveroption @server=N'GenericLinkedServer',
@optname=N'dist',
@optvalue=N'false'
GO
EXEC master.dbo.sp_serveroption @server=N'GenericLinkedServer',
@optname=N'pub',
@optvalue=N'false'
GO
EXEC master.dbo.sp_serveroption @server=N'GenericLinkedServer',
@optname=N'rpc',
@optvalue=N'false'
GO
EXEC master.dbo.sp_serveroption @server=N'GenericLinkedServer',
@optname=N'rpc out',
@optvalue=N'false'
GO
EXEC master.dbo.sp_serveroption @server=N'GenericLinkedServer',
@optname=N'sub', @optvalue=N'false'
GO
EXEC master.dbo.sp_serveroption @server=N'GenericLinkedServer',
@optname=N'connect timeout',
@optvalue=N'0'
GO
EXEC master.dbo.sp_serveroption @server=N'GenericLinkedServer',
@optname=N'collation name',
@optvalue=null
GO
EXEC master.dbo.sp_serveroption @server=N'GenericLinkedServer',
@optname=N'lazy schema validation',
@optvalue=N'false'
GO
EXEC master.dbo.sp_serveroption @server=N'GenericLinkedServer',
@optname=N'query timeout',
@optvalue=N'0'
GO
EXEC master.dbo.sp_serveroption @server=N'GenericLinkedServer',
@optname=N'use remote collation',
@optvalue=N'true'
GO
EXEC master.dbo.sp_serveroption @server=N'GenericLinkedServer',
@optname=N'remote proc transaction promotion',
@optvalue=N'true'
GO
There is however one small drawback to having linked servers with generic names. This is that at first glance you can’t tell which SQL Server instance the linked server is pointing to. Using the following query we can list all the linked servers in our instance and show where they are pointing to and which user context they are using on the remote server:
SELECT s.name,data_source,provider,
is_remote_login_enabled,is_rpc_out_enabled,
is_data_access_enabled,uses_self_credential,
remote_name
FROM sys.servers s INNER JOIN
sys.linked_logins ll on s.server_id=ll.server_id
WHERE s.server_id != 0
How to maintain and troubleshoot BizTalk Server databases
Microsoft BizTalk Server databases and the health of the databases are very important for a successful BizTalk Server messaging environment. This article discusses important things to consider when you work with BizTalk Server databases. These considerations include the following:
- You must disable the Auto Update Statistics and Auto Create Statistics Microsoft SQL Server options.
- You must set the Max Degree of Parallelism property correctly.
- Determine when you can rebuild BizTalk Server indexes.
- Locking, deadlocking, or blocking may occur.
- You may experience issues with large databases or tables.
- BizTalk SQL Server Agent jobs
- Service instances may be suspended.
- You may experience SQL Server and BizTalk Server performance issues.
- You should follow best practices in BizTalk Server.
Known issues
You must disable the Auto Update Statistics and Auto Create Statistics options
You must disable the Auto Create Statistics and Auto Update Statisticsoptions on the BizTalkMsgBoxDb database. To determine whether these settings are disabled, execute the following stored procedures in SQL Server:
exec sp_dboption 'BizTalkMsgBoxDB', 'auto create statistics' exec sp_dboption 'BizTalkMsgBoxDB', 'auto update statistics'
You should set the CurrentSetting setting to off. If this setting is set to on, turn it off by executing the following stored procedures in SQL Server:
exec sp_dboption 'BizTalkMsgBoxDB', 'auto create statistics', 'off' exec sp_dboption 'BizTalkMsgBoxDB', 'auto update statistics', 'off'
For more information, click the following article numbers to view the articles in the Microsoft Knowledge Base:
You must set the Max Degree of Parallelism property correctly
On the computer that is running SQL Server and hosting the BizTalkMsgBoxDb database, set the Max Degree of Parallelism run_value and config_value properties to a value of 1. To determine the Max Degree of Parallelism setting, execute the following stored procedure against the Master database in SQL Server:
exec sp_configure 'max degree of parallelism'
If the run_value and config_value properties are not set to a value of 1, execute the following stored procedure in SQL Server to set them to 1:
exec sp_configure 'max degree of parallelism', '1' reconfigure with override
For more information, click the following article numbers to view the articles in the Microsoft Knowledge Base:
Determine when you can rebuild BizTalk Server indexes
Most BizTalk Server indexes are clustered (index ID: 1). You can use the DBCC SHOWCONTIG SQL Server statement to display fragmentation information for the BizTalk Server tables.
The BizTalk Server indexes are GUID-based. Therefore, fragmentation typically occurs. If the Scan Density value that is returned by the DBCC SHOWCONTIG statement is less than 30 percent, the BizTalk Server indexes can be rebuilt during downtime.
Many BizTalk Server tables contain columns that use DataType definitions. Online indexing cannot be performed in these columns. Therefore, you should never rebuild the BizTalk Server indexes while BizTalk Server processes data.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
For more information about how to analyze the DBCC SHOWCONTIG statement output, visit the following Microsoft website:
Locking, deadlocking, or blocking may occur
Typically, locks and blocks occur in a BizTalk Server environment. However, these locks or blocks do not remain for an extended time. Therefore, blocking and deadlocking indicate a potential problem.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
You may experience issues with large databases or tables
I have seen that when the BizTalkMsgBoxDb database is larger than 5GB, performance problems can occur. Ideally, the BizTalkMsgBoxDb database should not be holding any data. The BizTalkMsgBoxDb database should be considered a buffer until the data is processed or moved to the BizTalkDTADb database.
An environment that uses a powerful SQL Server at the back end and many long-running orchestrations may have a BizTalkMsgBoxDb database that is larger than 5 GB. A high-volume environment that uses no long-running orchestrations should have a BizTalkMsgBoxDb database that is much smaller than 5 GB.
The BizTalkDTADb database does not have a set size. However, if performance decreases, the database is probably too large. Typically, 15 GB to 20 GB is considered too large. When you have large BizTalk Server databases, you may experience the following issues:
- The BizTalkMsgBoxDb database continues to grow. However, both the log file and the data size remain large.
- BizTalk Server takes a longer time than usual to process even a simple message flow scenario.
- Health and Activity Tracking (HAT) queries take a longer time than usual and may time out.
- The database log file is never truncated.
- The BizTalk SQL Server Agent jobs run slower than usual.
- Some tables are significantly larger or have too many rows compared to the usual table size.
Databases can become large for various reasons. These reasons may include the following:
- BizTalk SQL Server Agent jobs are not running
- Large number of suspended instances
- Disk failures
- Tracking
- Throttling
- SQL Server performance
- Network latency
Make sure that you know what is expected in your environment to determine whether a data issue is occurring.
By default, tracking is enabled on the default host. BizTalk requires that the Allow Host Tracking option be checked on a single host. When tracking is enabled, the Tracking Data Decode Service (TDDS) moves the tracking event data from the BizTalkMsgBoxDb database to the BizTalkDTADb database. If the tracking host is stopped, TDDS does not move the data to the BizTalkDTADb database and the TrackingData_x_x tables in the BizTalkMsgBoxDb database will grow.
We recommend that you dedicate one host to tracking. To allow for TDDS to maintain new tracking events in high-volume scenarios, create multiple instances of a single tracking host. No more than one tracking host should exist.
There can be too many rows in a table. There is no set number of rows that are too many. Additionally, this number of rows varies by what kind of data is stored in the table. For example, a dta_DebugTrace table that has more than 1 million rows probably has too many rows. A HostNameQ_Suspended table that has more than 200,000 rows probably has too many rows.
Use the correct BizTalk SQL Server Agent jobs
The BizTalk SQL Server Agent jobs are important for managing the BizTalk Server databases and for maintaining high performance.
The Backup BizTalk Server SQL Server Agent job is the only supported method to back up the BizTalk Server databases. This job requires all BizTalk Server databases use a Full Recovery Model. You should configure this job for a healthy BizTalk Server environment. The SQL Server methods can be used to back up the BizTalk Server databases only if SQL Server Agent is stopped and if all BizTalk Server host instances are stopped.
The MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server Agent job runs infinitely. Therefore, the SQL Server Agent job history never displays a successful completion. If a failure occurs, the job restarts within one minute and continues to run infinitely. Therefore, you can safely ignore the failure. Additionally, the job history can be cleared. You should only be concerned if the job history reports that this job constantly fails and restarts.
The MessageBox_Message_Cleanup_BizTalkMsgBoxDb SQL Server Agent job is the only BizTalk Server job that should not be enabled because it is started by the MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server Agent job.
The DTA Purge and Archive SQL Server Agent job helps maintain the BizTalkDTADb database by purging and archiving tracked messages. This job reads every row in the table and compares the time stamp to determine whether the record should be removed.
All BizTalk SQL Server Agent jobs except the MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server Agent job should be running successfully.
For more information about all the BizTalk Server SQL Server Agent jobs, click the following article number to view the article in the Microsoft Knowledge Base:
Service instances may be suspended
Service instances can be suspended (resumable) or suspended (not resumable). These service instances may be Messaging, Orchestration, or Port.
These service instances can make the BizTalkMsgBoxDb database grow unnecessarily and can be terminated. The following table lists what method can be used, depending on the BizTalk version:
| Group Hub | HAT | Terminate.vbs | Terminator Tool | |
| BizTalk Server 2010 | Yes | No | Yes | Yes |
| BizTalk Server 2009 | Yes | No | Yes | Yes |
| BizTalk Server 2006 R2 | Yes | Yes | Yes | Yes |
| BizTalk Server 2006 | Yes | Yes | Yes | Yes |
| BizTalk Server 2004 | No | Yes | Yes | Yes |
For more information about the Terminate.vbs script, visit the following MSDN website:
Caching instances do not appear in the Group Hub page, and you cannot suspend or terminate them. This restriction is a common cause of table growth. To prevent new zombie messages for the cache service instances in BizTalk Server 2006, install the hotfix in Microsoft Knowledge Base article 936536. This issue is fixed in BizTalk Server 2006 R2 and later versions.
Note A zombie message is a message that was routed but not consumed.
For more information, click the following article number to view the article in the Mirosoft Knowledge Base:
When a BizTalk Server host instance terminates, caching instances may not be removed. To resolve this behavior in BizTalk Server 2006, install the hotfix in Microsoft Knowledge Base article 944426. In BizTalk Server 2006 R2, install BizTalk 2006 R2 Service Pack 1. This issue is fixed in BizTalk Server 2009 and later versions.
For more information, click the following article numbers to view the articles in the Microsoft Knowledge Base:
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
You may experience SQL Server and BizTalk Server performance issues
BizTalk Server makes hundreds of short, very quick transactions to SQL Server within a minute. If the SQL Server cannot sustain this activity, BizTalk Server may experience performance issues. In Performance Monitor, monitor the Avg. Disk sec/Read, Avg. Disk sec/Transfer and Avg. Disk sec/Write Performance Monitor counters in the PhysicalDisk performance object. The optimal value is less than 10 ms (milliseconds). A value of 20 ms or larger is considered poor performance.
For more information about SQL Server performance, visit the following Microsoft website:
For more information about BizTalk Server 2004 database high availability, visit the following MSDN website:
For more information about BizTalk Server 2006 database high availability, visit the following MSDN website:
For more information, click the following article numbers to view the articles in the Microsoft Knowledge Base:
271509 How to monitor blocking in SQL Server 2005 and in SQL Server 2000
Best Practices in BizTalk Server
Start SQL Server Agent on the SQL Server. When the SQL Server Agent is stopped, the built-in BizTalk SQL Server Agent jobs that are responsible for database maintenance cannot run. This behavior causes database growth, and this growth may cause performance issues. BizTalk Server database maintenance has greatly improved in BizTalk Server 2004 Service Pack 2 (SP2) and later versions.
Put the SQL Server LDF and MDF files on separate drives. When the LDF and MDF files for the BizTalkMsgBoxDb and BizTalkDTADb databases are on the same drive, disk contention can occur.
If you do not benefit from message body tracking, do not enable this feature. However, it is a good idea to enable message body tracking while you develop and troubleshoot a solution. If you do this, make sure that you disable message body tracking when you are finished. When message body tracking is enabled, the BizTalk Server databases grow. If there is a business need that requires enabling message body tracking, confirm that the TrackedMessages_Copy_BizTalkMsgBoxDb and DTA Purge and Archive SQL Server Agent jobs are running successfully.
Typically, smaller transaction logs cause better performance. To keep the transaction logs smaller, configure the Backup BizTalk ServerSQL Server Agent job to run more frequently. For more information about BizTalk Server optimization, visit the following MSDN website:
The sp_ForceFullBackup stored procedure in the BizTalkMgmtDb database can also be used to help perform an ad-hoc full backup of the data and log files. The stored procedure updates the adm_ForceFullBackup table with a value 1. The next time the Backup BizTalk Server job runs, a full database backup set is created.
The BizTalk Server Best Practices Analyzer (BPA) can be used to evaluate an existing BizTalk Server deployment. The BPA performs numerous database-related checks. For more information about the BPA, visit the following Microsoft website:
Troubleshooting
The best troubleshooting steps for the BizTalk Server SQL Server databases depend on the kind of database issue, such as blocking or deadlocking. To troubleshoot a BizTalk Server database issue, follow these steps.
Step 1: Enable and run all required BizTalk SQL Server Agent jobs
All the BizTalk SQL Server Agent jobs except the MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb job should be enabled and running successfully. Do not disable any other job.
If a failure occurs, use the View History option in SQL Server to view the error information, and then troubleshoot the failure accordingly. Remember that the MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server Agent job runs infinitely. Therefore, you should only be concerned if the job history reports that the job constantly fails and restarts.
Step 2: Use the MsgBoxViewer tool
Collect MsgBoxViewer data while you reproduce an issue.
The MsgBoxViewer tool is useful for troubleshooting because it provides an HTML report that has detailed information about table sizes and the row count. The report can also help determine whether BizTalk Server is throttling. Additionally, the tool provides a snapshot of the BizTalk Server databases and the BizTalk Server configuration.
For more information about how to download the MsgBoxViewer tool, visit the following Microsoft website:
For more information about throttling in BizTalk Server, visit the following MSDN website:
When BizTalk Server is running slower than usual, run the MsgBoxViewer tool, and then review the generated HTML report for any problems. The Summary section lists warnings in yellow and potential problems in red.
Additionally, you can use the MsgBoxViewer tool output to determine which tables are the largest and have the most records. The following table lists the BizTalk Server tables that typically grow the largest. You can use this data to determine where a potential problem may exist.
| Table | Description |
|---|---|
| HostNameQ_Suspended | This table contains a reference to messages in the Spool table that are associated with suspended instances for the particular host. This table is in the BizTalkMsgBoxDb database. |
| HostNameQ | This table contains a reference to messages in the Spool table that are associated with the particular host and are not suspended. This table is in the BizTalkMsgBoxDb database. |
| Spool Parts Fragments |
These tables store actual message data in the BizTalkMsgBoxDb database. |
| Instances | This table stores all instances and their current status in the BizTalkMsgBoxDb database. |
| TrackingData_0_x | These four tables store the Business Activity Monitoring (BAM) tracked events in the BizTalkMsgBoxDb database for TDDS to move the events to the BAMPrimaryImport database. |
| TrackingData_1_x | These four tables store the tracked events in the BizTalkMsgBoxDb database for TDDS to move the events to the BizTalkDTADB database. |
| Tracking_Fragmentsx Tracking_Partsx Tracking_Spoolx | Two of each of these tables are in the BizTalkMsgBoxDb and BizTalkDTADb databases. One is online, and the other is offline. In BizTalk Server 2004 SP2 and in later versions, the TrackedMessages_Copy_BizTalkMsgBoxDb SQL Server Agent job moves tracked message bodies directly to these tables in the BizTalkDTADb database. In BizTalk Server 2004 Service Pack 1 (SP1) and in earlier versions of BizTalk Server 2004, the TrackedMessages_Copy_BizTalkMsgBoxDb SQL Server Agent job copies tracked message bodies into these tables in the BizTalkMsgBoxDb database. The TrackingSpool_Cleanup_BizTalkMsgBoxDb SQL Server Agent job purges the offline tables and makes the tables online while the job also takes the online tables offline. |
| dta_ServiceInstances | This table stores tracked events for service instances in the BizTalkDTADb database. If this table is large, the BizTalkDTADb database is probably large. |
| dta_DebugTrace | This table stores the Orchestration debugger events in the BizTalkDTADb database. |
| dta_MessageInOutEvents | This table stores tracked event messages in the BizTalkDTADb database. These tracked event messages include message context information. |
| dta_ServiceInstanceExceptions | This table stores error information for any suspended service instance in the BizTalkDTADb database. |
Consider the following scenarios.
HostNameQ_Suspended tables
If the HostNameQ_Suspended tables have many records, the tables could be valid suspended instances that appear in Group Hub or in HAT. These instances can be terminated. If these instances do not appear in Group Hub or in HAT, the instances are probably caching instances or orphaned routing failure reports. When suspended instances are terminated, the items in this table and their associated rows in the Spool and Instances tables are cleaned up.
In this scenario, handle the suspended instances by resuming them or terminating them. The BizTalk Terminator tool can also be used.
HostNameQ tables
If the HostNameQ tables have many of records, the following kinds of instances may exist:
- Ready-to-run instances
- Active instances
- Dehydrated instances
BizTalk Server needs time to “catch up” and process the instances. This table can grow when the incoming rate of processing outpaces the outgoing rate of processing. This scenario can occur when another problem occurs, such as a large BizTalkDTADb database or SQL Server disk delays.
Spool, Parts, and Fragments tables
If the Spool, Parts, and Fragments tables have many records, many messages are currently active, dehydrated, or suspended. Depending on the size, the number of parts, and the fragmentation settings in these tables, a single message may spawn all these tables. Each message has exactly one row in the Spool table and at least one row in the Parts table.
Instances table
The BizTalk Administrator should not allow for many suspended instances to remain in the Instances table. Dehydrated instances should only remain if the business logic requires long-running orchestrations. Remember that one service instance can be associated with many messages in the Spool table.
TrackingData_x_x tables
If the TrackingData_x_x tables are large, the Tracking host (TDDS) is not running or is not running successfully. If the tracking host instance is running, review the event logs and the TDDS_FailedTrackingData table in the BizTalkDTADb database for error information. If BizTalk is throttling with a state of 6 (large database), these tables can also be truncated by using the BizTalk Terminator tool.
If there is a large gap between the sequence numbers in the BizTalkMsgBoxDb TrackingData_x_x tables and the BAMPrimaryImport or BizTalkDTADb TDDS_StreamStatus tables, then TDDS may not move the data from the BizTalkMsgBoxDb database. To correct this, use the BizTalk Terminator tool to purge these tables and reset the sequence number.
On BizTalk Server 2006 R2, install BizTalk 2006 R2 Service Pack 1 to address a known issue with the tracking data. For more information, click the following article numbers to view the articles in the Microsoft Knowledge Base:
974563 List of Microsoft BizTalk Server hotfixes that are included in BizTalk Server 2006 R2 Service Pack 1
Tracking_Spool1 or Tracking_Spool2 tables
If the Tracking_Spool1 or Tracking_Spool2 tables become large in BizTalk Server 2004 SP1 and in earlier versions of BizTalk Server 2004, confirm that the TrackingSpool_Cleanup_BizTalkMsgBoxDb SQL Server Agent job is enabled and running.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
For more information about a Database Maintenance SDK sample, visit the following MSDN website:
dta_DebugTrace table and dta_MessageInOutEvents
The dta_DebugTrace table is populated when Shape start and end is enabled on an orchestration. If the dta_DebugTrace table has many records, these orchestration debugging events are being used or were being used. If orchestration debugging is not required for regular operations, clear the check box for the Shape start and end option in the orchestration properties.
The dta_MessageInOutEvents table is populated when Message send and receive is enabled on orchestrations and/or pipelines. If these tracking events are not needed, clear the check box for this option in the orchestration and/or pipeline properties.
If these trace events are disabled or if a backlog exists in the BizTalkMsgBoxDb database, these tables may continue to grow because TDDS continues to move this data into these tables.
By default, global tracking is enabled. If global tracking is not necessary, it can be disabled. For more information, visit the following Microsoft website:
If the dta_DebugTrace table and/or the dta_messageInOutEvents table in the BizTalkDTADb database are too large, you can truncate the tables manually after you stop the tracking host. The BizTalk Terminator tool also provides this functionality.
In BizTalk Server 2004, the dtav_FindMessageFacts view in the BizTalkDTADb database prevents the dta_MessageInOutEvents table from truncating. To work around this behavior, follow these steps:
- Stop the tracking host and the DTA Purge and Archive job.
- If you want to truncate the dta_messageInOutEvents table, save and then delete the dtav_FindMessageFacts view. To do this, follow these steps:
- In SQL Server, access the dtav_FindMessageFacts view in the BizTalkDTADb database.
- Right-click the dtav_FindMessageFacts view, click All Tasks, and then click Generate SQL Script. When the Generate SQL Scripts dialog box opens, make no changes, and then click OK.
- Name the file dtav_FindMessageFacts.sql, and then click Save.
- Right-click the dtav_FindMessageFacts view, and then click Delete. Click Drop All.
You can now truncate the table(s). If you truncate the dta_messageInOutEvents table, you must also truncate the dta_url table. The dta_url table only exists in BizTalk Server 2004.
When you are finished, follow these steps to re-create the dtav_FindMessageFacts view:
- Open a new query in SQL Server.
- In the Available Databases list, select the BizTalkDTADb database.
- Execute your saved dtav_FindMessageFacts.sql script. This will re-create the view in the BizTalkDTADb database.
Restart the tracking host and the DTA Purge and Archive job.
dta_ServiceInstanceExceptions table
The dta_ServiceInstanceExceptions table typically becomes large in an environment that regularly has suspended instances.
Step 3: Investigate deadlock scenarios
In a deadlock scenario, enable DBCC tracing on the SQL Server so that the deadlock information is written to the SQLERROR log.
In SQL Server 2005 and later versions, execute the following statement:
DBCC TRACEON (1222,-1)
In SQL Server 2000, execute the following statement:
DBCC TRACEON (1204)
Additionally, use the PSSDiag utility to collect data on the Lock:Deadlock event and theLock:Deadlock Chain event.
The BizTalkMsgBoxDB database is a high-volume and high-transaction Online Transaction Processing (OLTP) database. Some deadlocking is expected, and this deadlocking is handled internally by the BizTalk Server engine. When this behavior occurs, no errors are listed in the error logs. When you investigate a deadlock scenario, the deadlock that you are investigating in the output must be correlated with a deadlock error in the event logs.
For more information about PSSDiag for SQL, click the following article number to view the article in the Microsoft Knowledge Base:
Step 4: Look for blocked processes
Use Activity Monitor in SQL Server to obtain the server process identifier (SPID) of a locking system process. Then, run SQL Profiler to determine the SQL statement that is executing in the locking SPID.
To troubleshoot a locking and blocking issue in SQL Server, use the PSSDiag for SQL utility to capture all the Transact-SQL events that have the blocking script enabled.
In SQL Server 2005 and later versions, you can specify the blocked process threshold setting to determine which SPID or SPIDs are blocking longer than the threshold that you specify.
For more information about PSSDiag for SQL, click the following article number to view the article in the Microsoft Knowledge Base:
For more information about the blocked process threshold, visit the following MSDN website:
Step 5: Install the Latest BizTalk Server Service Pack and Cumulative Update
BizTalk Server 2006 R2 and later versions have moved to a Cumulative Update (CU) model. The cumulative updates will contain the latest hot fixes. BizTalk Server 2006 R2 Service Pack 1 is also available:
BizTalk Server 2004 SP1 has no built-in purging and archiving functionality for the BizTalkDTADb database. This functionality is included with BizTalk Server 2004 SP2. Depending on the size of the BizTalkDTADb database, installing BizTalk Server 2004 SP2 may take hours because the Setup program purges the BizTalkDTADb database.
For information about the known issues when you install BizTalk Server 2004 Service Pack 2, click the following article number to view the article in the Microsoft Knowledge Base:
Delete all the data
If the databases are too large or if the preferred method is to delete all data, all the data can be deleted.
CautionDo not use this method in any environment where the data is business critical or if the data is needed.
BizTalkMsgBoxDb Database Purging Steps
To delete all data in the BizTalkMsgBoxDb database, you can use the BizTalk Terminator tool. Otherwise, follow these steps.
NoteThis action deletes all messages. Be extremely cautious if you follow these steps in a production environment.
- Back up all BizTalk Server databases. Remember, the BizTalkMgmtDb.dbo.sp_ForceFullBackup stored procedure can be used to force a full backup of the data and log files. Execute this stored procedure, and then execute the Backup BizTalk Server SQL Agent job.
- Copy the Msgbox_cleanup_logic.sql script from Drive:\Program Files\Microsoft BizTalk 200x\schema to the SQL Server.
- Execute this SQL script against the BizTalkMsgBoxDb database to update the bts_CleanupMsgbox stored procedure.
- Stop all BizTalk hosts, services, and custom isolated adapters. If you use HTTP or the SOAP adapter, restart the IIS services.
- Execute the bts_CleanupMsgbox stored procedure on all the BizTalkMsgBoxDb databases.
- Restart all host instances and BizTalk Server services.
For information about a known issue with the bts_CleanupMsgbox stored procedure in BizTalk Server 2006, click the following article number to view the article in the Microsoft Knowledge Base:
BizTalkDTADb database purging options
To delete all data from the BizTalkDTADb database, you can use the the BizTalk Terminator tool. Otherwise, use one of the following methods.
NoteBoth methods delete all messages. Method 2 is faster.
- Method 1:
- Back up all BizTalk Server databases.
- Execute the dtasp_PurgeAllCompletedTrackingData stored procedure. For more information about the dtasp_PurgeAllCompletedTrackingData stored procedure, visit the following MSDN website:
Note This action deletes all completed messages.
- Method 2:
- Back up all BizTalk databases.
- Execute the dtasp_CleanHMData stored procedure. Only use this option if the BizTalkDTADb database contains many incomplete instances that must be removed.
To do this, follow these steps:- Stop all BizTalk hosts, services, and custom isolated adapters. If you use HTTP or the SOAP adapter, restart the IIS services.
- Execute the dtasp_CleanHMData stored procedure on the BizTalkDTADb database.
- Restart all hosts and BizTalk Server services.
BizTalk Server 2004-only steps
To delete all data from the BizTalkDTADb database in BizTalk Server 2004, follow these steps.
NoteThis action deletes all completed messages.
- Back up all BizTalk Server databases.
- Stop all BizTalk hosts, services, and custom isolated adapters. If you use HTTP or the SOAP adapter, restart the IIS services.
- Install the hotfix in Microsoft Knowledge Base article 894253. Follow the steps in this Knowledge Base article to run the Bts_tracking_shrinkexistingdatabase.sql script in SQL Server 2000.
For information about the dtasp_PruneTrackingdatabase stored procedure, click the following article number to view the article in the Microsoft Knowledge Base:894253 FIX: The dtasp_PruneTrackingdatabase() stored procedure may take many hours to clean up the DTA database in BizTalk Server 2004 - Restart all hosts and BizTalk services.
Note If you must have the tracking data, back up the BizTalkDTADb database, restore the database to another SQL Server, and then purge the original BizTalkDTADb database.
If you need help to analyze the MsgBoxViewer data or the PSSDiag output, contact Microsoft Customer Support Services. For a complete list of Customer Support Services telephone numbers and information about support costs, visit the following Microsoft website:
Unable to edit the DCOM settings for IIS WAMREG admin service on a Windows Server 2008 R2 when trying to configure Kerberos Authentication for Role Centers
I came across an issue recently where we were configuring Enterprise Portal and Role Centers to use Kerberos authentication. One of the steps in the whitepaper (and also as given here http://technet.microsoft.com/en-us/library/ee355057.aspx) is to configure DCOM settings to grant the business connector proxy user account Launch and Activation permissions for the IIS WAMREG admin service package. We were able to do this successfully on a Windows Server 2003 R2/2008 system, however on a Windows Server 2008 R2 system the options are all greyed out/disabled in Component Services.
This is by design. Due to new security considerations, some core system components only grant the local internal account, TrustedInstaller, Full Control permission instead of the local Administrators group.
To be able to modify the settings of IIS WAMREG admin service” on a Windows Server 2008 R2 system, you need to grant the local Administrators group permissions to its registry key as follows:
Registry information: Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall the operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.
| a. | Expand Component Services, expand Computers, expand My Computer, and expand DCOM Config. |
| b. | Right-click IIS WAMREG admin Service, and then click Properties. |
| c. | Click the Security tab. |
| d. | Under Launch and Activation Permissions, click Edit. |
| e. | Under Group or user names section, add the Business Connector Proxy User account, and select the user account |
| f. | Under Permissions for the Business Connector Proxy User account, select the Local Launch and Local Activation checkboxes |
| g. | Click OK and OK and close the Component Services management console. |
REFERENCES:
The TrustedInstaller account was introduced with Windows Server 2008 – see http://technet.microsoft.com/en-us/library/cc731677(WS.10).aspx for more details.
Keyboard Shortcuts in SQL Query Analyzer
CTRL-SHIFT-F2 -- Clear all bookmarks. CTRL+F2 -- Insert or remove a bookmark (toggle). F2 -- Move to next bookmark. SHIFT+F2 -- Move to previous bookmark. ALT+BREAK -- Cancel a query. CTRL+O -- Connect. CTRL+F4 -- Disconnect. CTRL+F4 -- Disconnect and close child window. ALT+F1 -- Database object information. CTRL+SHIFT+DEL -- Clear the active Editor pane. CTRL+SHIFT+C -- Comment out code. CTRL+C or Ctrl+Insert -- Copy CTRL+X or Shift+Del -- Cut SHIFT+TAB -- Decrease indent. CTRL+DEL -- Delete through the end of a line in the Editor pane. CTRL+F -- Find. CTRL+G -- Go to a line number. TAB -- Increase indent. CTRL+SHIFT+L -- Make selection lowercase. CTRL+SHIFT+U -- Make selection uppercase. CTRL+V or Shift+Insert -- Paste. CTRL+SHIFT+R -- Remove comments. F3 -- Repeat last search or find next. CTRL+H -- Replace. CTRL+A -- Select all. CTRL+Z -- Undo. F5 or Ctrl + E -- Execute a query. F1 -- Help for Query Analyzer. SHIFT+F1 -- Help for the selected Transact-SQL statement. F6 -- Switch between query and result panes. Shift+F6 -- Switch panes. CTRL+W -- Window Selector. CTRL+N -- New Query window. F8 -- Object Browser (show/hide). F4 -- Object Search. CTRL+F5 -- Parse the query and check syntax. CTRL+P -- Print CTRL+D -- Display results in grid format. CTRL+T -- Display results in text format. CTRL+B -- Move the splitter. CTRL+SHIFT+F -- Save results to file. CTRL+R -- Show Results pane (toggle). CTRL+S -- Save CTRL+SHIFT+INSERT -- Insert a template. CTRL+SHIFT+M -- Replace template parameters. CTRL+L -- Display estimated execution plan. CTRL+K -- Display execution plan (toggle ON/OFF). CTRL+I -- Index Tuning Wizard. CTRL+SHIFT+S -- Show client statistics CTRL+SHIFT+T -- Show server trace. CTRL+U -- Use database
KERBEROS CONFIGURATION – SPN USAGE
What SPN do I use and how does it get there?
This month has turned into an Kerberos Month for me. I thought I would share my response to the questions as it will probably be helpful for someone. Here was the comment that started the conversation. And, by the way, this was actually a good question. I actually see this kind of comment a lot in regards to SPN placement. Not necessarily the setup aspect of it, but for SPN’s in general.
“In prior versions of setup we used to be able to specify the port number for the default and Named Instance. Now, (SQL 2008 & R2) it takes the defaults. 1433 and Dynamic for Named Instances.
If you want to use Kerberos with TCP, you need to know the port number to create the SPN. For Default instances, if you’re using 1433 then you’re ok. But, Named Instances listen on a dynamic port by default, and since you can’t set the port number, any SPN you create will probably be wrong and Kerberos won’t work. It would be great if we could ask the user if they want to change the port number during setup, like we did with SQL 2000.”
Let’s have a look at Books Online first.
Registering a Service Principal Name http://msdn.microsoft.com/en-us/library/ms191153.aspx
This article goes through the different formats that are applicable to SQL 2008 (they are the same for R2 as well). It also touches on two items that are important to understand. 1. Automatic SPN Registration and 2. Client Connections. Here is the excerpt from the above article in regards to Automatic SPN Registration.
Automatic SPN Registration
When an instance of the SQL Server Database Engine starts, SQL Server tries to register the SPN for the SQL Server service. When the instance is stopped, SQL Server tries to unregister the SPN. For a TCP/IP connection the SPN is registered in the format MSSQLSvc/<FQDN>:<tcpport>.Both named instances and the default instance are registered as MSSQLSvc, relying on the <tcpport> value to differentiate the instances.For other connections that support Kerberos the SPN is registered in the format MSSQLSvc/<FQDN>:<instancename> for a named instance. The format for registering the default instance is MSSQLSvc/<FQDN>.
Manual intervention might be required to register or unregister the SPN if the service account lacks the permissions that are required for these actions.
What does this mean? It means that if the SQL Service account is using Local System or Network Service as the logon account, we will have the permission necessary to register the SPN against the Domain Machine Account. By default, the machine accounts have permission to modify themselves. If we change this over to a Domain User Account for the SQL Service account, things change a little. By default a Domain User does not have the permission required to create the SPN. So, when you start SQL Server with a Domain User Account, you will see an entry in your ERRORLOG similar to the following:
2010-03-05 09:39:53.20 Server The SQL Server Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service. Error: 0x2098, state: 15. Failure to register an SPN may cause integrated authentication to fall back to NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies.This permission is called “Write servicePrincipalName” and can be altered through an MMC snap in called ADSI Edit. For instructions on how to modify this setting, refer to Step 3 in the following KB Article. WARNING: I do NOT recommend you do this on a Cluster. We have seen issues with this causing connectivity issues due to Active Directory Replication issues if more than one Domain Controller is used in your environment.
How to use Kerberos authentication in SQL Server http://support.microsoft.com/kb/319723
So, if I enable that permission, lets see what the SQL Service does. I have two machines I’m going to use for this. ASKJCTP3 (running the RC build of 2008 R2) and MySQLCluster (SQL 2008 running a Named Instance called SQL2K8).
SetSPN Details:
SPN’s with TCP and NP enabled on Default Instance:
C:\>setspn -l sqlservice Registered ServicePrincipalNames for CN=SQL Service,OU=Services,DC=dsdnet,DC=local: MSSQLSvc/ASKJCTP3.dsdnet.local:1433 MSSQLSvc/ASKJCTP3.dsdnet.local
SPN’s with only NP enabled on Default Instance:C:\>setspn -l sqlservice Registered ServicePrincipalNames for CN=SQL Service,OU=Services,DC=dsdnet,DC=local: MSSQLSvc/ASKJCTP3.dsdnet.local
SPN’s with TCP and NP enabled on Clustered Named Instance: C:\>setspn -l sqlservice Registered ServicePrincipalNames for CN=SQL Service,OU=Services,DC=dsdnet,DC=local: MSSQLSvc/MYSQLCLUSTER.dsdnet.local:54675 MSSQLSvc/MYSQLCLUSTER.dsdnet.local:SQL2K8
SPN’s with only NP enabled on a Clustered Named Instance:C:\>setspn -l sqlservice Registered ServicePrincipalNames for CN=SQL Service,OU=Services,DC=dsdnet,DC=local: MSSQLSvc/MYSQLCLUSTER.dsdnet.local:SQL2K8
Lets look at what the client will do. When I say client, this could mean a lot of different things. Really it means an Application trying to connect to SQL Server by way of a Provider/Driver. NOTE: Specifying the SPN as part of the connection is specific to SQL Native Client 10 and later. It does not apply to SqlClient or the Provider/Driver that ships with Windows.Service Principal Name (SPN) Support in Client Connections http://msdn.microsoft.com/en-us/library/cc280459.aspx
Based on this, if I have a straight TCP connection, the Provider/Driver will use the Port for the SPN designation. Let’s see what happens when I try to make connections using a UDL file. For the UDL I’m going to use the SQL Native Client 10 OleDb Provider. Starting with SNAC10, we can specify which SPN to use for the connection. This provides us some flexibility when we control how the application is going to connect. Note: This is not available with the Provider/Driver that actually ship with Windows. I also will show what the Kerberos request looks like in the network trace. This will show us, what SPN is actually being used. All of these connection attempts were made using ASKJCTP3 which is a Default Instance.
Being this is a Default Instance, I added the Instance Name SPN manually.
C:\>setspn -l sqlservice Registered ServicePrincipalNames for CN=SQL Service,OU=Services,DC=dsdnet,DC=local: MSSQLSvc/ASKJCTP3.dsdnet.local:MSSQLSERVER MSSQLSvc/ASKJCTP3.dsdnet.local:1433 MSSQLSvc/ASKJCTP3.dsdnet.local MSSQLSvc/MYSQLCLUSTER.dsdnet.local:54675 MSSQLSvc/MYSQLCLUSTER.dsdnet.local:SQL2K8
Straight TCP with no SPN Specified:
![clip_image002[5]](http://blogs.msdn.com/blogfiles/psssql/WindowsLiveWriter/WhatSPNdoIuseandhowdoesitgetthere_765B/clip_image002%5B5%5D.jpg "clip_image002[5]")
58 1.796875 {TCP:7, IPv4:5} 10.0.0.3 10.0.0.1 KerberosV5 KerberosV5:TGS Request Realm: DSDNET.LOCAL Sname: MSSQLSvc/askjctp3.dsdnet.local:1433
TCP with specifying an SPN for the connection:
32 1.062500 {TCP:11, IPv4:5} 10.0.0.3 10.0.0.1 KerberosV5 KerberosV5:TGS Request Realm: DSDNET.LOCAL Sname: MSSQLSvc/ASKJCTP3.dsdnet.local:MSSQLSERVER
Forcing Named Pipes with no SPN specified:
68 1.828125 {TCP:21, IPv4:5} 10.0.0.3 10.0.0.1 KerberosV5 KerberosV5:TGS Request Realm: DSDNET.LOCAL Sname: MSSQLSvc/askjctp3.dsdnet.local
The way the provider/driver determines which SPN to use is based on the Protocol being used. Of note, starting in SQL 2008 we allowed for Kerberos to be used with Named Pipes. If you have a Named Instance and you are using the Named Pipes protocol, we will look for an SPN with the Named Instance specified. For a Default Instance and Named Pipes, we will just look for the SPN with no port or Named Instance Name specified as shown above.
With the ability to specify the SPN from the client side, you can see how you can easily manipulate, or even see how we will determine what SPN will be used.
Now that we know all of the above, lets go back to the original question. Your company may or may not want to enable the Write permission for the Domain User Account. If your company is not willing to open up the permission on the service account, then their only recourse will be to set a static port for the Named Instance instead of letting the Named Instance use a dynamic port. This would also be my recommendation for Clusters. In this case, you will need to know exactly what SPN’s are needed and create them manually using SetSPN or tool of your choice.
Even though we don’t provide the ability to set your port during setup, you can still modify the port settings for the Instance through the SQL Server Configuration Manager. This will allow you to set your static SPN’s as well as assist you with Firewall rules.
If you have more than 3 nodes in a Server 2008 Failover Cluster and upgrade to 2008 R2 SP1 you might get some problem. HOTFIX is available.
Validate SCSI Device Vital Product Data (VPD) test fails after you install Windows Server 2008 R2 SP1
| Hotfix Download Available View and request hotfix downloads// |
SYMPTOMS
//
- You configure a failover cluster that has three or more nodes that are running Windows Server 2008 R2 Service Pack 1 (SP1).
- You have cluster disks that are configured in groups other than the Available Storage group or that are used for Cluster Shared Volumes (CSV).
- These disks are online when you run the Validate SCSI Device Vital Product Data (VPD) test or the List Potential Cluster Disks storage validation test.
In this scenario, the Validate SCSI Device Vital Product Data (VPD)test fails. Additionally, you receive an error message that resembles the following:
The List Potential Cluster Disksstorage validation test may display a warning message that resembles the following:
RESOLUTION
//
The error and warning messages that are mentioned in the “Symptoms” section may also occur because of other issues such as storage problems or an incorrect configuration. Therefore, you should investigate other events, check the storage configuration, or contact your storage vendor if this issue still occurs after you install the following hotfix.
Hotfix information
If the hotfix is available for download, there is a “Hotfix download available” section at the top of this Knowledge Base article. If this section does not appear, submit a request to Microsoft Customer Service and Support to obtain the hotfix.
NoteIf additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. For a complete list of Microsoft Customer Service and Support telephone numbers or to create a separate service request, visit the following Microsoft Web site:
Prerequisites
Registry information
Restart requirement
Hotfix replacement information
File information
Windows Server 2008 R2 file information notes
- The files that apply to a specific product, SR_Level (RTM, SPn), and service branch (LDR, GDR) can be identified by examining the file version numbers as shown in the following table.
Collapse this tableExpand this table
Version Product SR_Level Service branch 6.1.760 1. 17xxx Windows Server 2008 R2 SP1 GDR 6.1.760 1. 21xxx Windows Server 2008 R2 SP1 LDR - The MANIFEST files (.manifest) and the MUM files (.mum) that are installed for each environment are listed separately in the “Additional file information for Windows Server 2008 R2” section. MUM and MANIFEST files, and the associated security catalog (.cat) files, are extremely important to maintain the state of the updated components. The security catalog files, for which the attributes are not listed, are signed with a Microsoft digital signature.
For all supported x64-based versions of Windows Server 2008 R2
| File name | File version | File size | Date | Time | Platform |
|---|---|---|---|---|---|
| Failoverclusters.agent.interop.dll | 6.1.7601.17514 | 11,776 | 20-Nov-2010 | 13:39 | x64 |
| Failoverclusters.validation.bestpracticetests.dll | 6.1.7601.21710 | 131,072 | 22-Apr-2011 | 19:59 | x86 |
| Failoverclusters.validation.common.dll | 6.1.7601.21710 | 15,872 | 22-Apr-2011 | 19:59 | x86 |
| Failoverclusters.validation.generaltests.dll | 6.1.7601.21710 | 278,528 | 22-Apr-2011 | 19:59 | x86 |
| Failoverclusters.validation.storagetests.dll | 6.1.7601.21710 | 165,376 | 22-Apr-2011 | 19:59 | x64 |
| Failoverclusters.validation.wizard.dll | 6.1.7601.21710 | 163,840 | 22-Apr-2011 | 19:59 | x86 |
For all supported IA-64-based versions of Windows Server 2008 R2
| File name | File version | File size | Date | Time | Platform |
|---|---|---|---|---|---|
| Failoverclusters.agent.interop.dll | 6.1.7601.17514 | 11,776 | 20-Nov-2010 | 10:35 | IA-64 |
| Failoverclusters.validation.bestpracticetests.dll | 6.1.7601.21710 | 131,072 | 22-Apr-2011 | 18:56 | x86 |
| Failoverclusters.validation.common.dll | 6.1.7601.21710 | 15,872 | 22-Apr-2011 | 18:56 | x86 |
| Failoverclusters.validation.generaltests.dll | 6.1.7601.21710 | 278,528 | 22-Apr-2011 | 18:56 | x86 |
| Failoverclusters.validation.storagetests.dll | 6.1.7601.21710 | 178,176 | 22-Apr-2011 | 18:56 | IA-64 |
| Failoverclusters.validation.wizard.dll | 6.1.7601.21710 | 163,840 | 22-Apr-2011 | 18:56 | x86 |
Additional file information
//
Additional file information for Windows Server 2008 R2
//
Additional files for all supported x64-based versions of Windows Server 2008 R2
//
| File name | Amd64_c2ba436ef182e0a5928c7085a1c15a1c_31bf3856ad364e35_6.1.7601.21710_none_9ab972a7d49f9cf5.manifest |
| File version | Not applicable |
| File size | 718 |
| Date (UTC) | 22-Apr-2011 |
| Time (UTC) | 22:46 |
| File name | Amd64_microsoft-windows-f..rcluster-validation_31bf3856ad364e35_6.1.7601.21710_none_8391722feb62e788.manifest |
| File version | Not applicable |
| File size | 6,157 |
| Date (UTC) | 22-Apr-2011 |
| Time (UTC) | 22:57 |
Additional files for all supported IA-64-based versions of Windows Server 2008 R2
//
| File name | Ia64_10d0cccfb7f4951daa8f04e3b22712cd_31bf3856ad364e35_6.1.7601.21710_none_00d442193a2cb4e4.manifest |
| File version | Not applicable |
| File size | 716 |
| Date (UTC) | 22-Apr-2011 |
| Time (UTC) | 22:46 |
| File name | Ia64_microsoft-windows-f..rcluster-validation_31bf3856ad364e35_6.1.7601.21710_none_27747aa233037f4e.manifest |
| File version | Not applicable |
| File size | 6,155 |
| Date (UTC) | 22-Apr-2011 |
| Time (UTC) | 22:46 |
About me
This blog is my online toolbox. I will blog things I need to remember and find useful. Instead of making a private link repository I will do it on this public blog and maybe someone will find it helpful. I will also post solutions to problems I solve myself and if it helped, please let me know in a comment.
About me
I am a Senior Solution Architect working at a consulting firm in Norway. My expert area is Microsoft network and platform infrastructure. Beside that I have 12 years experiance as a Senior Technical Specialist on the following areas: Exchange Server, SQL Server, Lync and Microsoft infrastructure (Active Directory, DHCP, DNS, ADFS, Certificates). Some experience in TMG/UAG and other security solutions.
-
Archives
- June 2013 (2)
- December 2012 (4)
- November 2012 (1)
- August 2012 (8)
- July 2012 (1)
- June 2012 (3)
- May 2012 (14)
- April 2012 (8)
- March 2012 (7)
- February 2012 (4)
- January 2012 (9)
- December 2011 (6)
-
Categories
-
RSS
Entries RSS
Comments RSS
GAPTHEGURU 