MISDivision Blog

Sharepoint Notes and Tricks

jonas — Mon, 16 Apr 2012 16:47:01 +0000

When it comes to SharePoint and moving farms and databases from one server to the other, I felt it would be good to make some public notes and things for anyone who has to work with this program and configurations next.

- When performing a backup, there are a couple different types you can choose from, however, only two really matter; the Site Backup and Full Backup. Either way, both these options can be used for importing/exporting and can both be found in the Central Admin Console.
Site Backup – this will backup the preferences of your site and its configurations for the actual site, not the data. If any custom changes are made to the Central Admin page or the site itself, this should be exported along with the full backup.
Full Backup – this will backup everything when it comes to the SharePoint server: the farm, the configurations (data wise), the databases, SQL express settings, everything except custom site changes. This is basically the way to go to take the entire SharePoint server contents from one site to the other.

- Some things to keep in mind when you’re having issues is:

The Central Admin Console a registered service with IIS, so any changes that are made that affect the operation to the point to where the console is no longer accessible might mean the service has to be restarted.
The Central Admin Console is basically the GUI for the site itself. It will allow you to control everything about the site, its configurations, and how it operates
There is a what’s called “SharePoint Products Configuration” app that comes with the installation that allows you to basically roll the clock back on different products within the SharePoint environment leaving the current data untouched, think of it as a Windows System Restore. If you have any issues with the farm configuration, the CA console, site issues, etc, run this app and it will set everything back to default. Just be sure when it asks you to keep it on the same farm/database. You’ll find this in the Start Menu.
In order for some changes to be made by either the CA console or the app mentioned above, the SharePoint Central Admin Service must be turned off for a certain period of time. A reboot is not necessary but once the service is turned off and no longer recognizable by the related apps, it allows you to make certain changes now that were refused before (i.e. rolling back the CA console and getting an error).
When you perform a backup and you designate the location its being stored to, make sure the location is accessible by everyone within the folder security properties. For example, if you put it on the root of the C drive and try to perform a backup it will give you access denied to that location.
If you accidently turn off the Central Admin Console and its no longer accessible on the server, use the “SharePoint Products Configuration” app in the Advanced Settings to remove the website from the current server (keep it attached to the farm). Stop the SharePoint IIS services in IIS Manager and leave them for about five minutes. Then use the same SharePoint app and select to have the web applet on the current server, make sure during this whole process you keep the current farm selected. If done correctly, the CA Console should now be working using the original ID and password.
There can be multiple farms per site but only one site per server. If a different site has to be created for whatever reason, it will have to be installed on a different server running the same operating system and SharePoint version.

Think that about covers it but I might add more and come back to this.

How To Configure Database Mirroring and Database Replication with Publisher Fail-over Partnership With Microsoft SQL Server 2008 R2

Andrew Kuhlmann — Fri, 24 Feb 2012 20:37:55 +0000

Database mirroring and replication are both very popular technologies utilized by organizations which rely on business critical SQL databases in order to distribute load among various Database nodes and to provide high availability. It is possible to setup either database mirroring or replication without using Publisher Failover Partnership, however this leads to scenarios where in the case that the Primary mirror database fails over to the backup server replication connections are lost and servers which rely on replication will be unable to synchronize until the primary server comes back online. Furthermore this can lead to replication sessions becoming compromised in cases where there is a long time duration before the primary server is restored.

For this case we have the following scenario:

A critical set of database servers which has grown from a relatively small deployment has expanded over the course of some time to include fully redundant high capacity primary database servers which are utilizing mirroring to provide high availability. Additionally there has been several servers added over the life of this environment which are utilizing replication, wherein the primary database server has been configured as the sole publisher and distributor of the publication. It has become evident that the replication sessions are too critical to leave in this state and therefor they must be redeployed to utilize a remote distributor database and publisher failover partnership.

In the lab environment I will demonstrate the following procedure:

Remove existing publications, subscriptions and distributor database.
Remove database mirroring.
Take backup of Live Production Database.
Restore Backup of Live Production Database to Mirror.
Create Distributor Database on Remote Witness and Distributor server.
Configure Privileges on Distributor Database to Allow Backup Publisher.
Create Publication.
Deploy Database Mirroring.
Associate Secondary Mirror Server as a Publisher on Distributor Database.
Add Mirrored Server as Publisher to Distributor.
Add Agent Parameters for Failover Partner.

Server Role	Server Name
Primary Mirror	sqldev-01.itcloudsuite.com
Backup Mirror	sqldev-02.itcloudsuite.com
Distribution Database, Mirroring Witness	sqldev-03.itcloudsuite.com
Subscriber Server	sqldev-04.itcloudsuite.com
Subscriber Server	sqldev-05.itcloudsuite.com

Reference Articles:

Replication and Database Mirroring: http://msdn.microsoft.com/en-us/library/ms151799.aspx

Configuring Remote Distributor: http://msdn.microsoft.com/en-us/library/ms147363.aspx

Manually Removing Replication: http://support.microsoft.com/kb/324401

How To Prepare a Mirror Database for Mirroring: http://technet.microsoft.com/en-us/library/ms189047.aspx

Step 1. Remove existing publications, subscriptions and distributor database.

As this environment has previously been configured to utilize both mirroring and replication, we’ll need to do some cleanup. Firstly we should run the following command at the existing Distributor database as a way to verify the presence of an existing distributor database.

USE [master]

exec sp_get_distributor

GO

In the above screenshot the column ‘distribution db installed’ returns a Boolean value of 1 indicating that a distribution database exists on this server. We need to remove this before we proceed as part of sterilizing the environment prior to configuring our environment for fail-over partnership. The procedure for removing all of this is formally documented by Microsoft here, however I’ll briefly run through as this is a very important part of this procedure and getting this wrong could lead to additional downtime in a live deployment.

First we need to ‘Drop all subscriptions that are configured for the replication.’

Depending on your environment, you may need to perform slightly different queries in order to remove all of your subscriptions. In our case we have a single snapshot replication session which is configured as a Push subscription. The query I’ll use to remove the subscription will be run on the Publisher server where the Database name is ‘MirrorRepTest’ and the Publication name is ‘MirrorRepTest-Pub’ as follows:

USE MirrorRepTest

GO

EXEC sp_dropsubscription @publication = N’MirrorRepTest-Pub’, @article = N’all’, @subscriber = N’all’, @destination_db = N’all’

If you need to drop pull subscriptions instead, or in addition to some push subscriptions, then you would need to use the following query first on the Subscriber server:

USE

GO

EXEC sp_droppullsubscription @publisher = N’’, @publisher_db = N’’, @publication = N’’

And then from the Publisher server:

USE

GO

EXEC sp_dropsubscription @publication =N’’, @subscriber = N’’, @article = N’all’, @destination_db = N’’

Note that the above procedure also varies for Merge subscriptions, see MS guidance if needed.

The second step for cleanly removing existing replication is to ‘Drop all publications that are configured for the replication.’

For this demonstration, we’re working with a ‘Transactional’ Publication. The procedure to drop Merge publications differs from the following, if needed see MS guidance. The command I that follows will be run on the publisher server where the Publication database name is ‘MirrorRepTest’ and the Publication name is ’MirrorRepTest-Pub’. This query will utilize two stored procedures (sp_droppublication & sp_replicationdboption) which will basically drop all of the articles from the publication and then configure the replicated database to no longer participate in replication.

USE MirrorRepTest

GO

EXEC sp_droppublication @publication = N’MirrorRepTest-Pub’

USE master

GO

EXEC sp_replicationdboption @dbname = N’MirrorRepTest’, @optname = N’publish’, @value = N’false’

The final step for removing replication is to ‘Drop the distributor that is configured for the replication.’

Firstly on the Publisher we will need to execute the following script in order to drop the subscriber designation which is assigned to the subscriber server.

USE master

GO

EXEC sp_dropsubscriber @subscriber = N’sqldev-03′, @reserved = N’drop_subscriptions’

Next, we will run the following script on the Distributor server in order to remove the Distributor.

USE master

GO

EXEC sp_dropdistributor @no_checks = 1

Now that all of the replication configurations have been cleanly removed, we can simply use the SQL Management Studio GUI to remove any lingering push subscription records on the subscriber servers.

Step 2. Remove database mirroring.

Removing database mirroring is a lot less complicated than removing replication, for this I would advise simply using the GUI in SQL Studio. If for you need to fail-over first, remember to do this prior to removing mirroring.

After removing mirroring, whichever database was the mirror at the time the mirroring session was broken will end up in a restoring state.

The restoring state indicates that the database is waiting for completion of the log restore before the database will enter a normal state. However, this also will prevent you from being able to remove this database. Although, if you intend to re-establish mirroring on this database this is a good state to leave the databaes in… But in some cases you may need to remove it. In that case, you would want to use the following script to force a recovery. In this case I’m executing against the DB called ‘MirrorRepTest’

restore database MirrorRepTest with recovery

Now that I’ve run this command, you can see the database is back to a normal state.

If needed I can perform normal operations such as dropping or altering this database now.

Note that in cases where databases become stuck “In Recovery” the above will not work. In those cases, if you need to remove the database… My method is simply to stop the entire SQL server and delete the actual MDF/LDF files and then start the server. Once you do this and refresh the list of databases, the stuck database will be gone.

Step 3. Take backup of Live Production Database.

Now that all the preliminary cleanup of our environment is complete, we’re ready to proceed with taking a backup of the live production database in preparation for configuring Mirroring. In my experience with huge databases it’s often good to use something like a USB hard-drive in order to transport the databases efficiently. However, for this demonstration I’ll simply be taking a regular backup to the C: drive of the server. There’s nothing particularly special about this operation other than to make sure you include this in your planning as this operation can take a long time to complete when dealing with huge databases.

Step 4. Restore Backup of Live Production Database to Mirror.

Please note that the following scenario is somewhat limited in scope and as always I would recommend reviewing the official Microsoft guidance here prior to performing this operation in a live environment.

The method I prefer for performing this operation starts with creating an empty database which will receive the backup taken in step 3. In our scenario this database will have the same name as the principal server ‘MirrorRepTest’. It’s important at this point to specify the correct logical drive/folder where you ultimately want your data files to reside.

Now that the DB is ready to receive the data, we’ll go ahead and restore the backup to this database. Firstly you’ll need to click on the following:

From the next menu I simply want to select my data source, in our case it’s just a file on the C: that I’ve copied via remote desktop… However in a production scenario it would likely be either a USB drive, or possibly a SAN location or something of that nature.

Next I need to click on the ‘Options’ tab on this menu and make sure to specify ‘RESTORE WITH NORECOVERY’ in order for the DB to be in the correct state to initiate mirroring. You will also need to select WITH REPLACE as we’re over-writing the blank database that we created previously.

Once you’ve completed the above you may be ready to go. However, in a lot of cases you’ll also need to take another backup of transaction logs. In that case you’ll simply take a transaction log backup instead of a full backup, and then restore it to the database in the same way except this time using the logs… You’ll need to select NORECOVERY during that procedure as well. Once that’s complete you will be ready to proceed with the rest of the setup and you will see the database in a ‘Restoring…’ state on the SQL Studio GUI.

Step 5. Create Distributor Database on Remote Witness and Distributor server.

Official Microsoft guidance for this portion can be found here.

Now we’re getting into the real meat of this setup. In our lab environment I’ve specified a single server as a witness and a distributor server however this distributor server does not have to be on the same server as the witness as they are completely independent of each other.

The first script we’ll use will utilize stored procedures to setup the distributor database itself on the specified server. This must be run against what is to be the Distributor server.

USE [master]

exec sp_adddistributor @distributor= ‘sqldev-03′, @password= ‘v3rys3cur3p4ss’

GO

USE [master]

exec sp_adddistributiondb @database= ‘distributor’, @data_folder= ‘C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA’, @data_file= ‘distributor.mdf’, @log_folder= ‘C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA’, @log_file= ‘distributor.ldf’

GO

Assuming this script is successful you should get a return showing a bunch of tables and clustered indexes being created that will be used for the distributor database.

Step 6. Configure Privileges on Distributor Database to Allow Backup Publisher.

Once the distributor database is created, we’ll need to configure it to allow what is to become our primary mirror server to act as a publisher. As an additional note, we will first need to create a shared folder on the distributor server. In order for replication to function properly you’ll need to grant access to the appropriate SQL Server Agents to access this folder.

For making the needed configuration we will use the following script:

USE [master]

exec sp_adddistpublisher @working_directory= ‘\\sqldev-03\RepShare’, @publisher= ‘sqldev-01′, @distribution_db= ‘distributor’

GO

Step 7. Create Publication.

We’re now ready to create our primary publication. In our case, SqlDev-01 is to be the primary publisher as it will be the primary mirror and so the configurations will be made on that server.

If you remember, the first thing we did was check to see if a distributor database was installed on our server using the following script:

USE [master]

exec sp_get_distributor

GO

If this distributor database is already installed, then we’ll need to use the following command to get rid of it.

USE master

GO

EXEC sp_dropdistributor @no_checks = 1

Assuming the distributor database is not present, when we go to create the publication using the SQL Studio GUI wizard, the first menu prompt will be asking us which Distributor database we want to use. At this point we’re going to want to select the remote distributor we created in step 5. Again, if this menu does not appear then you’ve messed up somewhere along the way removing the Distributor.

The next screen will ask you for a password. This is the password that you’ve entered in the script in step 5. In my lab it was ‘v3rys3cur3p4ss’.

Once that password is entered the rest of the wizard is just your standard publication creation. Make sure to select the correct Database. In my lab environment we’ll be creating a ‘Transactional publication’. With all tables and views selected, and creating a snapshot immediately to later initialize subscriptions with.

For the Agent Security menu I’m simply using my administrator account in the domain. This account needs access to that share we created earlier.

As a general rule, always check ‘Generate a script file with steps to create the publication’ even if you’re letting the default script run. This can come in very handy if you run into problems with a publication later on.

If you check the script that it generates, you’ll notice that the first command it issues is as follows:

use master

exec sp_adddistributor @distributor = N’sqldev-03′, @password = N’‘

GO

This is running a stored procedure which is configuring the distributor database used by this SQL Server. We basically made this configuration on the first screen when we chose sqldev-03 as the distributor, however the command isn’t actually issued until the script runs. Note that the password field is blank as a security measure.

The reason I’m pointing out this command is that if you think about it, the backup mirror server will need to have this configuration made as well. Why? Well, if it’s going to become the publisher in the event of a failover… It will need to know what distributor to connect to.

Step 8. Deploy Database Mirroring.

Previously we had prepared the database for mirroring, but didn’t actually get around to setting it up. We could have done it earlier, but we’re doing it now instead…

Since the databases are already created, all we need to do is use the SQL Studio GUI to create the mirroring session. One thing to note here, at least in my experience, you’ll have a lot easier time doing this if you first generate a couple SQL accounts with full privileges solely for the purpose of mirroring on the primary, secondary, and witness servers. Make sure to configure these accounts not to expire passwords too… For obvious reasons.

For the first few screens you’re just picking the needed servers and specifying the service accounts that we intend to use for the mirroring session.

Once you complete the wizard steps, you’ll be prompted as to whether you wish to start the mirroring session. Obviously you want to attempt this. At this point you may encounter a failure if SQL detects that it needs a transaction log backup. If that’s the case, refer back to step 4. Remember that you’re taking a transaction log backup though, and not another full backup. The transaction log backup should not take nearly as long on a large database as it would to take a full backup.

Also one thing to note, if you get stuck here and it seems like the restore transaction log menu is grayed out.. Don’t Panic! You simply need to cancel out of the mirroring session and refresh the secondary mirror database, and it will go back to being in a restoring state. This is caused by mirroring trying to grab the DB to bring it into the fold. The main thing here you need to be sure of is to leave the database in a NORECOVERY state by selecting the following:

If all goes well, you should now have an active mirroring session. We’re now ready to move on to finalizing the replication configurations.

Step 9. Associate Secondary Mirror Server as a Publisher on Distributor Database

This command is going to specify that the secondary mirroring server is allowed to be a publisher on the distributor server. This is needed in the event of a fail-over. This command is run on the distributor server.

USE [master]

exec sp_adddistpublisher @working_directory= ‘\\sqldev-03\RepShare’, @publisher= ‘sqldev-02′, @distribution_db= ‘distributor’

GO

In this case I’m specifying sqldev-02 which is the secondary mirror.

Step 10. Add Mirrored Server as Publisher to Distributor.

Remember the command I made you look at when we created the publication? Well we need to run that now, this command is going to be run on the Secondary Miror Server. This command is a stored procedure which is configuring the remote distributor server to be used as a distributor for any publications.

use master

exec sp_adddistributor @distributor = N’sqldev-03′, @password = ‘ v3rys3cur3p4ss’

GO

If you’ll remember when we created the distributor we specified ‘v3rys3cur3p4ss’ as the password. Hopefully it’s obvious that you’d be better off using something else.

Step 11. Add Agent Parameters for Failover Partner.

The last thing we need to do to the publication itself is to configure the ‘–PublisherFailoverPartner’ parameter on the various agents involved in the publication. This operation should be taking place on the Distributor server.

First we’ll want to use the sp_help_agent_profile stored procedure to return a list of agents via the following script.

exec sp_help_agent_profile

As you can see in the above screenshot I’ve highlighted 4 rows. For the rest of this procedure we’ll be making configurations to each of these Agent profiles to configure the ’–PublisherFailoverPartner’ parameter. The agent_type field refers to the type of agent that each profile corresponds to. For this procedure requires that all snapshot, log reader, and queue reader agents be configured. Note that in some environments the profile_id’s will be different from the following commands and you will need to refer back to the ‘sp_help_agent_profile’ output in order to script out the following configurations.

So for instance, with the above output I would need to run the following script

exec sp_add_agent_parameter @profile_id = 1, @parameter_name = N’-PublisherFailoverPartner’, @parameter_value = N’SQLDEV-02′

exec sp_add_agent_parameter @profile_id = 2, @parameter_name = N’-PublisherFailoverPartner’, @parameter_value = N’SQLDEV-02′

exec sp_add_agent_parameter @profile_id = 3, @parameter_name = N’-PublisherFailoverPartner’, @parameter_value = N’SQLDEV-02′

exec sp_add_agent_parameter @profile_id = 11, @parameter_name = N’-PublisherFailoverPartner’, @parameter_value = N’SQLDEV-02′

In the above command I am specifying the secondary mirror which is SQLDEV-02 as the parameter value for the publisherfailoverpartner parameter name.

Now that the above configurations have been made, you simply need to restart the SQL Agents on both of the servers involved in mirroring.

Once those servers are back online, you’re ready to proceed with deploying as many subscriptions as you need using push subscriptions. There shouldn’t be anything special about deploying the actual subscribers themselves assuming everything above has been completed successfully.

Microsoft SQL Server 2008: Resetting a SQL User Password

ilya — Fri, 20 Jan 2012 18:18:54 +0000

Sometimes, you might run into a situation where you need to reset the password for a SQL user account. The process is quite simple and is described below.

Step 1: Open an elevated command prompt and run the following command to stop SQL services:

NET STOP MSSQLSERVER

Step 2: Next, we will need to start SQL Server in single-user mode. This is done by running the following command:

NET START MSSQLSERVER /m

Step 3: Now, open up SQL Server Management Studio and log in using Windows Authentication:

Step 4: Expand Security, and then Logins. Find your SQL user account, right click it and select Properties.

Step 5: Enter in the new password and confirm it, then click OK.

Step 6: Go back to your elevated command prompt, and restart SQL Server with the following two commands:

NET STOP MSSQLSERVER
NET START MSSQLSERVER

Step 7: Confirm that your new login is working and you’re done!

How to set up a transactional replication pull subscription in Windows SQL Server 2008 R2 using SQL commands

William Gannon — Fri, 20 Jan 2012 08:41:57 +0000

In SQL server, replication allows data to be synchronized between two or more databases. One server acts as a publisher which has a publication subscribed to by servers; the publication specifies what data is to be distributed to the subscriber servers. In transactional replication, a snapshot of the publication is created on a subscriber server; any new transactions on the publication database are propagated onto the subscriber server. In order to instantiate replication, you will need to create a subscription on the subscriber server. This article will show you step by step how to create a transactional replication subscription. It assumes you have create a publication and specified a publisher and distributor server.

The basic steps to create the subscription are as follows:

1. Run the snapshot agent.

2. Take a backup of the database to be replicated

3. Restore the backup onto the subscriber server

4. Run publisher SQL commands to add a subscription for the subscriber.

5. Run subscriber SQL commands to finish creating the subscription and to add the subscription agent.

Be aware that setting up replication can be a time intensive process. For example, taking a backup of a 1TB database could take as long as 8 hours; the restore would take about the same amount of time. After setting up replication, it may take up to several days for the involved databases are synchronized.

First, you’ll need to run the snapshot agent on the publication on the publisher server. Inside of the SQL Server Management Studio, Right-click the publication and select View Snapshot Agent Status.

Next, select Start to create the snapshot. Wait until the snapshot has finished.

So long as there aren’t any problems, you should see a screen like the one below. You can close the dialog box.

The next step is to create a backup of the database to be replicated. Right-click the database, select Tasks and then select Back Up…

Here, you will specify the source database, the type of backup, the name of the backup set, and where the back up will be saved. For the backup type, select Full. If you are going to save to a hard drive, you need to select Disk under Destination and then select Add to specify where the backup will be saved. Select OK to start the backup.

This dialog box comes up when you select Add… Select … to browse for a backup destination. Select OK when done.

Once the backup has completed, a dialog box will appear saying so. Even if the progress shows Executing (100%), the backup is not really complete until you see the following dialog box appears. Select OK to close out the backup window.

Now on your subscriber server, restore the backup. Move the backup file you specified in the previous step to the subscriber server. In Management Studio, right-click Databases and select Restore Database…

Here you specify the database, the backup file to be used for the restore, and the backup sets to restore. The database should be the same name as the database being replicated. Check the box next to the backup set. Select OK to start the restore.

Similar to the backup, the restore is not complete until you see a success dialog box.

Now, that the backup has been restored on the subscriber server, the commands to create the subscription need to be run. Text in italics is a description of what to put into the command. You can see specific examples in the images following each respective command. On the publisher server, run the following command:

EXEC sp_addsubscription
@publication = N’publication name‘,
@subscriber = N’subscriber server‘,
@destination_db = N’destination database name‘,
@subscription_type = N’pull’,
@sync_type = N’initialize with backup’,
@backupdevicetype = N’disk’,
@backupdevicename = N’backup file location‘,
@article = N’all’,
@update_mode = N’read only’,
@subscriber_type = 0;

There are a few different subscription types. A pull subscription will have agent processes run on the subscriber server, placing less load on the distributor server. You should note that if you had placed a backup file and moved it via an external device, you’ll have to move the USB device back to the publisher after restoring the backup.

Jump to the subscriber server and run the following command:

EXEC sp_addpullsubscription
@publisher = N’publisher server‘,
@publisher_db = N’publisher database‘,
@publication = N’publication name‘,
@independent_agent = ‘true’,
@subscription_type = ‘pull’,
@description = ‘description’,
@update_mode = ‘read only’,
@immediate_sync = 1

Lastly, run this command on the subscriber:

exec sp_addpullsubscription_agent
@publisher = N’publisher name‘,
@publisher_db = N’publisher database‘,
@publication = N’publication name‘,
@distributor = N’distributor name‘,
@job_login = N’login for job‘,
@job_password = N’password‘,
@subscriber_security_mode = 1,
@frequency_type = 64,
@frequency_interval = 0,
@frequency_relative_interval = 0,
@frequency_recurrence_factor = 0,
@frequency_subday = 0,
@frequency_subday_interval = 0,
@active_start_time_of_day = 0,
@active_end_time_of_day = 235959,
@active_start_date = 20120113,
@active_end_date = 99991231,
@enabled_for_syncmgr = N’False’,
@distributor_security_mode = 1,
@distributor_login = N’login to connect to distributor‘,
@distributor_password = N’password‘,
@alt_snapshot_folder = N”,
@working_directory = N”,
@use_ftp = N’False’

The security mode = 1 means using Windows authentication which is possible with domain user logins. If you need to use SQL authentication, the security mode should be set to 0.

If no errors occurred, the replication should be established now. You can check replication status using the replication monitor. Right-click the Replication folder and select Launch Replication Monitor.

The replication monitor will show the replication latency between the publisher and subscriber servers.

You can get a more accurate view of the replication health by viewing the details on the subscription. Inside of the replication monitor, select the Subscription Watch List tab. Right-click the subscription and select View Details.

Inside of the details on the subscription, select the Undistributed Commands tab. You will see the number of commands to be applied to the subscriber and a time estimate to apply the commands. If you have a large production database to replicate, there will probably be a lot of commands to apply since taking the original backup. You’ll know that the replication health is good so long as the number of commands is going down. Once replication has caught up completely, the number of commands to applied will be 0; as stated earlier, it may take several days to catch up completely if you have a large database.

How To Configure MISDivision Hosted Lync

Andrew Kuhlmann — Tue, 27 Sep 2011 21:33:35 +0000

Configuring your hosted MISDivision Lync account is easy, simply follow these steps.

From your Lync client, click the gear icon and then navigate to tools –> options

From here you will see the options menu.

Next, click the “Personal” tab on the left and then the “Advanced…” button. This will pop-up Advanced Connection Settings.

From here, insert the internal server name or IP address and External server name or IP Address fields as seen below with the server: sip.misdivision.com

Once you have complete this, simply login with your assigned user name and password.

How To Automatically Login to External SharePoint Site

Andrew Kuhlmann — Fri, 05 Aug 2011 17:07:20 +0000

The following steps will allow you to automatically log in to a SharePoint site which does not share your work stations Active Directory domain.

1. In Internet Explorer, click “tools” then click “internet options”
2. Click the “Secuirty” tab and then click the “Local Intranet” icon
3. Click the “Sites” button and then click “Advanced”
4. Type or otherwise enter the domain for the SharePoint site into the “add website to the zone:” input box and click the “Add” button

Next, as this is an external site you must store a credential for the site via this method:

1. Navigate to Control Panel\User Accounts\Credential Manager on your Windows computer. This can be accessed either via the control panel, or by simply entering “Control Panel\User Accounts\Credential Manager” into a My Computer window.
2. Click “Add a windows credential”
3. In the window that appears, enter your SharePoint sites domain.
4. Enter in your username/password.

After completing the above steps you should automatically be logged into the SharePoint site without needing to authenticate each time.

How to set mailboxes to forward and save a copy in Exchange 2010

Andrew Kuhlmann — Wed, 08 Jun 2011 19:51:13 +0000

As an Exchange 2010 administrator a common request is for a mailbox to exist for forwarding purposes, but also to reserve a copy of any received email in the mailbox.

Achieving this is simple when you’re using the Exchange management console. Simply edit the mailbox properties and click the mail flow tab, delivery options, and use the GUI to input values.

However when editing this using PowerShell commands isn’t immediately obvious due to the confusing names given to mailbox properties by Exchange.

See example code:

$mailboxID = “example.local/Microsoft Exchange Hosted Organizations/example.com/John Smith”
$ForwardingAddress = “johnsmith@contoso.com”
set-mailbox -identity $mailboxID -forwardingsmtpaddress $ForwardingAddress -DeliverToMailboxAndForward $true

This requires two input variables. The ID of the mailbox, found using the get-mailbox cmdlet… And the address to which email should be forwarded. The “DeliverToMailboxAndForward” property gets changed to $true which will enable sending a forward as well as keeping a copy.

How to manage Usage Quotes in SharePoint 2010

Andrew Kuhlmann — Wed, 08 Jun 2011 19:36:56 +0000

Sharepoint 2010 site collections are assigned Usage Quotas in order to dictate how much disk space and processing power is allocated to a given site. This is useful to allow multiple sites to co-exist on the same server without negatively impacting other sites due to excessive usage.

Managing usage quotas for a given site can be achieved through two methods. Either you can specify usage individually for each site, or you can assign templates to any number of sites effectively duplicating the usage quotas throughout.

Unfortunately there doesn’t appear to be an obvious Powershell method to manage quota templates, however there are ways to assign quota templates once you have created them through the web interface of the central administration site.

From central administration, click on Application Management, then click Specify Quota Templates. You will then be presented with the following interface:

In this example we have specified two items:

100 MB of disk usage allowed with a warning at 75mb (this is very conservative level of usage allowed)
300 Usage points, with a warning at 200 points. (default amount)

Edit these items based on an educated estimation of the potential growth of a given SharePoint site. For more information regarding planning quotas for your site, see this TechNet article.

Assigning this template can be accomplished using the following PowerShell code at command line or in a script:

$siteurlmain = “http://sharepoint.example.com”
Set-SPSite -Identity $siteurlmain -QuotaTemplate “test”

You may also configure usages for site collections on the central administration site using the GUI.

How to rename a Domain Controller

Kevin Viera — Sat, 04 Jun 2011 21:16:47 +0000

Today I’m going to show you how to rename a Domain Controller. Before we can rename the DC, we must prepare the server first. You can use this checklist as a guide to make sure your server is ready or copy and paste this link into your browser http://technet.microsoft.com/en-us/library/cc816631(WS.10).aspx. The actual command to rename it is fairly simple. One thing yo must remember is that the Forest and Domain Functional Level should be Windows Server 2008 to proceed with the following task.

Tutorial:

Open your command prompt and run the following code:

rendom /list
The previous command will outputs an XML file (Domainlist.xml) to the directory where rendom resides. You edit that file to change your domain configuration to the new domain name. i.e ForestDNSZones, DomainDNSZones, Netbios name. After you modified that file you will need to run:

rendom /showforest

That command will shows you the future configuration, verify and make changes if necessary
Next you will need to upload the changes you have made in the XML file by running:

rendom /upload
You will need to verify readiness of Domain Controller(s) by running:

rendom /prepare
Next execute domain rename instructions by running:

rendom /execute
After thats finishes up successfully, you should also run GPFIXUP tool to fix up GPO references to your old domain name by running:

gpfixup /olddns:(your old dns)/newdns:(your new dns)
Lastly, run:

rendom /clean

Once you are finish, the server will need a reboot. After the server reboot you can log back into your AD and verify your new domain.

Why does allocating large databases take so long by default with Microsoft SQL?

Andrew Kuhlmann — Wed, 25 May 2011 19:26:47 +0000

A common problem which occurs when going to allocate a new database in Microsoft SQL is an extremely long operation which will occur by default due to a disk zeroing operation that is performed when creating a new database. By default this will take a very long time even on the most powerful of database servers.

The reason behind this is fairly simple to understand. Rather than deleting a file, SQL actually goes out and zeroes the space on the drive. Obviously zeroing the space on the drive is a lot more intensive of an operation than simply flagging it as deleted and allowing the disk controller to simply overwrite that sector next time it needs some space.

Of course there’s a very minor security risk here in that if someone were able to take total control of this disk they could theoretically use a disk recovery utility to read any data that was previously existing. Otherwise, there is really no disadvantage to simply erasing the space.

In order to allow SQL Server to allocate database quickly using Instant File Initialization, a security policy change needs to be made. This change can be made on either a computer level or a domain level. In most circumstances this would likely be made on a domain level in order to reduce administration overhead.

To enable Instant File Initialization perform the following steps:

1. Run secpol.msc on a SQL server. Expand Local Policies, click User Rights Assignment. On the right side, right click/properties “Perform Volume Maintenance Tasks.”

From there, you’ll see the following menu. Simply add the service account for your SQL database engine. You can also add the instance itself by its local object which will be something like: SQLServerMSSQLUser$ (computer name) $MSSQLSERVER

This may change based on if your SQL instance is named, and can be confirmed by using the secpol.msc snap-in to determine the actual name of the local account.

Also note that when you go to browse/add this in the properties menu for the actual security policy that you’ll need to select your computer name instead of the domain name.

Again, assigning this permission by the computer or by the domain service account accomplishes the same thing and is up to the administrator to determine based on their organizational security policy.