Automatically Redirect HTTP requests to HTTPS on IIS 7 using URL Rewrite 2.0

In a previous article I covered the installation URL Rewrite 2.0 for IIS 7. This is a plug-in for IIS 7 that allows you to manipulate URL’s.

URL Rewrite has a GUI to allow you to enter rules within IIS 7; in the background all this does is edit the web.config file of the site. I will show you how to create a rule both ways.

In the following example we will redirect HTTP to HTTPs using URL Rewrite. You will need the following items completed in order for this to work correctly.

– SSL Certificate for site installed in IIS.
– Site properly installed and configured for SSL (site set up and binding in IIS configured).
– URL Rewrite 2.0 is installed on the sever.

GUI Version

– Select the website you wish to configure
– In the “Features View” panel, double click URL Rewrite

You will notice there are currently no rules configured for this site. Click “Add Rules…” in the Actions menu to the right of the “Features View” panel

Use the default “Blank rule” and press “OK”.

When editing a rule there are the “Name” field and 4 configuration pull down boxes.

– Enter “Redirect to HTTPS” in the name field.
– Next we will configure the first configuration pull down box called “Match URL”, on the right side of “Match URL” press the down arrow to expand the box.

Within the “Match URL” configuration box we will set the following settings:

Requested URL: Matches the Pattern
Using: Regular Expressions
Pattern: (.*)

We can now edit the next configuration pull down box which is “Conditions”, Press “Add…” to add a new condition to the configuration.

We will configure the condition with the following settings:

Condition Input: {HTTPS}
Check if input string: Matches the Pattern
Pattern: ^OFF$

Press “OK”

You should see your condition in the list of conditions.

For this setting we do not need to configure the “Server Variables” pull down box. Continue onto the “Action” configuration box and pull down the box by selecting the arrow on the right. We will configure the following settings for the “Action” configuration:

Action Type: Redirect
Redirect URL: https://{HTTP_HOST}/{R:1}
Redirect Type: See Other (303)

Press “Apply” then press “Back to Rules”

You should now see the rule configured on the main screen of the URL Rewrite module.

Test your site, it should now redirect from HTTP to HTTPS.

If we exam the web.config file we can see where the rule was entered. If we entered the rule directly into the web.config file it would show up in the GUI.

Web.Config Rule

You can also edit the web.config file of the site directly and you will be able to see the rule in the GUI. You will need to enter the following within the <system.webServer> </system.webServer> elements.

1
2
3
4
5
6
<rule name="Redirect to HTTPS" stopProcessing="true">
<match url="(.*)" />
<conditions><add input="{HTTPS}" pattern="^OFF$" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="SeeOther" />
</rule>

When implementing this solution you need to make sure to use relative paths for all references on your page because there is a possibility you will get a warning asking you if you want to display secure and insecure items. For example, if you have a logo on your page and the URL to this logo is http://domain/images/logo.jpg, do not use the whole path because including the http:// will hard code this image to use http and not https. Instead use /images/logo.jpg.

Credits goes to:

Automatically Redirect HTTP requests to HTTPS on IIS 7 using URL Rewrite 2.0

How do I move SQL Server database files

you don’t mind stop the database from working, then you can DETACH it, move the files and then ATTACH it.

  • Right click on the name of the database
  • Select Properties
  • Go to the Files tab
  • Make a note of the Path and FileName of MDF and LDF files. This step is important in case you don’t want to end up searching for missing files…
  • Right click on the database name
  • Select Tasks -> Detach
  • Move the files where you want
  • Right click on the Databases node of your server
  • Select Attach
  • Click on the Add button
  • Point to the new location
  • Click OK

BizTalkDTADb grows too large – How to purge and maintain the database?

1. How to maintain the BizTalkDTADb?

Each BizTalk service instance running is processing data and while the data is processed, BizTalk tracks it and saves it in the BiztTalk Tracking Database. This means that the Tracking Database will grow indefinitely over time which is obviously not a viable option.
There is an SQL job called “DTA Purge and Archive (BizTalkDTADb)” that is installed on the BizTalk SQL Server which is used for cleaning up (deleting old tracking information) the BizTalkDTADb. That job is not enabled by default so the first thing that should be done after installing BizTalk server is to configure and enable the job. See here for information about how the cleanup process works and here for information on how to configure the SQL job. Basically, the job calls a single stored procedure on the BizTalkDTADb and once edited should looks like the following:

exec [dbo].[dtasp_BackupAndPurgeTrackingDatabase] 1, 0, 1, ‘\\MyBizTalkServer\backup’, null, 0

The 4 first parameters are the one that you need to know about. The 2 first are the number of hours and days for which completed instances will be cleaned up. The third one is the number of days after which even non completed instance will be cleaned up. The fourth is the location of the backup folder.
This means that the SQL job will back up the BizTalkDTADb each time it runs, making that backup files will fill up your disk subsystem pretty quickly if nothing is done about it! Backups are important in case of a Database crash and that the Tracking Database needs to be restored.

If you do not consider the Tracking Database to be of enough importance to be backed up and have the extra burden to manage the backups, you can modify the “DTA Purge and Archive (BizTalkDTADb)” SQL job as explained here. This way, the job will only purge the tracking database without backing it up. It is especially applicable for development and QA environments and might also apply to your production environment.
In short, the only change that needs to be done in the SQL job is to modify the T-SQL statement run by the job. It needs to execute the SP dtasp_PurgeTrackingDatabase instead of dtasp_BackupAndPurgeTrackingDatabase.

The final T-SQL statement executed by the SQL job will be similar to the following:

declare @now as datetime
set @now = GetUTCDate()
exec [dbo].[dtasp_PurgeTrackingDatabase] 0, 3, 6, @now

In this case I keep complete instances in the Tracking DB for 3 days and incomplete one for 6 days, everything older should be purged. As you see there is no path to specify for the backup location as no database backup is executed.

Instead of modifying the original SQL job you could alternatively disable it and create a new job with the appropriate T-SQL call. That is how I have done it myself and consider it to be a best practice.
Moreover, I scheduled the job to run every 5 minutes. This has proven to be a good time interval. I used to run the job every 30 minutes only but I ever encountered cases where the clean up procedure did not keep up with the amount of tracked data and I ended up with a huge tracking database which I had to purge manually, as I will explain next.
So, a 5 minutes interval to run the job seems to also be a best practice from my experience.

2. How to manually purge the BizTalkDTADb?

You will have to manually purge the BizTalkDTADb database if it grew too large either because the clean up procedure was not started or the clean up procedure could not keep up with the amount of data saved in the Tracking Database.
This is explained in details here but, in short, the important points are:

– All the BizTalk services used by BizTalk needs to be stopped. This means all the BizTalk host service instances, Enterprise SSO, BizTalk Rules Engine, EDI service, BAM, BAS and IIS if they are used.

– Open Microsoft SQL Server Management Studio and run the following SQL statement on the BizTalkDTADb: exec dtasp_PurgeAllCompletedTrackingData

Once the procedure is executed, a lot of space will have been freed in the Tracking Database. The database will nevertheless still take the same amount of space on the disk subsystem because deleting data in a database does not reduce the size the database takes on the disk. If you want to reduce its size on the disk, you need to shrink it. You can do that in 2 ways:

1. Through SQL Server Management Studio, right click on the BizTalkDTADb database, click on Tasks > Shrink > Database

How to shrink BizTalkDTADb database using SQL Server Management Studio

2. Through T-SQL using the DBCC SHRINKDATABASE command:
DBCC SHRINKDATABASE (BizTalkDTADb);
The reference of the T-SQL DBCC SHRINKDATABASE command can be found here.

Another useful trick is the ability to truncate the Log file (which should not be done on production as it “breaks” the backup). See some information about it here: Truncating the Database Log File.

 

Full Credits goes to:

Francois Malgreve

BizTalkDTADb grows too large – How to purge and maintain the database?

The format of the specified network name is invalid

if you are un-able to start Websites in the IIS and receiving fallowing errors “The format of the specified network name is invalid” couple quick things you can look into remedy to problem.

First on the server drilldown to this Reg key.

HKEY_LOCAL_MACHINE
SYSTEM
CurrentControlSet
Services
HTTP
Parameters
ListenOnlyList
Make sure, the IP Address listed there is the IP correct IP address configured on the NIC card of the service ( correct interface) if not make the proper changes.

 

After this you need to open CMD type

Net stop http /y

 

net start w3svc

image

now you should be able to start the websites under IIS…

 

SQL Backup Maintenance Plan

Open management studio >>connect to SQL Server>>Expand Management>>Right Click Maintenance plan>>Select New Maintenance Plan

Give name as you like ( FullBackupDaily) it will open designer window.Left side you can see ToolBox tab.

Select Backup Database task and double click or drag and drop it to designer pane.

Edit the Task for options>> connection as local,Backup type as Full,Specify the Databases which u want to include for this backup.

Provide valid path s backup directory (check backup integrity for best practice)

2. just full backup –already covered in above steps

3. full bak file should be with date, like testdb20110708.bak, testdb20110709.bak, consequently day by day.

our plan will create backups as you expect,Now schedule it as per your requirement.

to schedule please chek for ” subplan schedule” option.

select frequency as daily ,time as 5 Am.

4. just keep the recent 2 days bak files, like testdb20110708.bak and testdb20110709.bak

We can use Maintenance cleanup task to achieve this

drag and drop Maintenance cleanup task from ToolBox >>edit >>select backup files>>provide your backup files location>>file extension as Bak>>Check Delete files as ..>>Provide 2 days in Delete files older than following box.

5. backup to a remote disk–already covered in above steps,but i recommend you to take backup into local drive first, later you can copy to remote disk if require.

6. if could, how to fullfil differential and transactional log backup that will occurs every 24 hours and 1 hour respectitively?

You can perform using same above steps but change backup type and schedule accordingly for each maintenance plan .

Error SharePoint Server “Device is not ready” – Event 6482

  1. Stop the Windows SharePoint Services Timer service (Found in Windows Services)
  2. Navigate to the cache folder In Windows Server 2008, the configuration cache is in the following location: Drive:\ProgramData\Microsoft\SharePoint\Config In Windows Server 2003, the configuration cache is in the following location: Drive:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config Locate the folder that has the file “Cache.ini” (Note: The Application Data folder may be hidden. To view the hidden folder, change the folder options as required)
  3. Back up the Cache.ini file.
  4. Delete all the XML configuration files in the GUID folder. Do this so that you can verify that the GUID folder is replaced by new XML configuration files when the cache is rebuilt.
  5. Note When you empty the configuration cache in the GUID folder, make sure that you do not delete the GUID folder and the Cache.ini file that is located in the GUID folder.
  6. Double-click the Cache.ini file.
  7. On the Edit menu, click Select All. On the Edit menu, click Delete. Type 1, and then click Save on the File menu. On the File menu, click Exit.
  8. Start the Windows SharePoint Services Timer service
  9. Note The file system cache is re-created after you perform this procedure. Make sure that you perform this procedure on all servers in the server farm.
    1. Make sure that the Cache.ini file in the GUID folder now contains its previous value. For example, make sure that the value of the Cache.ini file is not 1.

 

Date Format

You can create calculated column instead.

For example:

1.      you have the date column like “Created”

2.      Create new calculated column, type the formula like “TEXT(Created, “dd-mmm-yyyy”)”

Now you can use this column displayed in your view.

The date format is dictated by Locale. This is effected by what locale the site is created is. It can be changed on an individual basis by clicking on the User ID drop down in the top right -> MySettings -> My Regional Settings -> Change the Locale.

Hello world!

Welcome to WordPress. This is your first post. Edit or delete it, then start writing!

Logo Redirect to Root Site Collection

<SharePoint:SPLinkButton NavigateUrl=”//” CssClass=”ms-siteicon-a” runat=”server” id=”onetidProjectPropertyTitleGraphic” >
<SharePoint:SiteLogoImage CssClass=”ms-siteicon-img” name=”onetidHeadbnnr0″ id=”onetidHeadbnnr2″ LogoImageUrl=”/_layouts/15/images/siteIcon.png?rev=23″ runat=”server”/>
</SharePoint:SPLinkButton >

SQL Server 2012 for SharePoint 2013 checklist

 

  1. Use multiple: SQL Aliases (separate 1 for search).
  2. Dedicate SQL Server for SharePoint.
  3. Set max degree of parallelism (MAXDOP) to 1 for instances of SQL (SP will do this when SP is installed).  Number of processes for each SQL statement.
  4. Mixed mode authentication – Don’t install SQL 2012 for SP in mixed mode auth unless you have good reason (the only reason I have heard of is from Todd Klindt’s podcast that mentions Access Services needs to use the SA account.  If you have other database that need SQL permission access consider moving them to a dedicate SQL instance.
  5. SQL Server 2012 AlwaysOn Availability Groups are a new high availability and disaster recovery solution that are an alternative to database mirroring and log shipping solutions. AlwaysOn Availability Groups support a set of primary read-write databases and up to four sets of secondary databases that can be set as read-only.
  6. Memory: You can set the max memory each SQL instance can use.  If the machine is dedicate to only provide SQL for SharePoint, the max setting is total memory minus 4GB for the OS.  See image 3.
  7. Model DB: Increase initial size and autogrowth settings – fix growth sizes.  I would start  with 100MB for the mdf and 20MB for the ldf for initial sizes.  Autogrowth on content db’s I start with 50MB growth for the mdf and 25MB for the log file (ldf).  See image1 below.
  8. Model DB: Don’t modify DB Collation after install.
  9. Model DB: Use Full recovery model on the Model system database – Simple prevents large log files.
  10. Avoid giant ldf log files … (don’t use DCC_Shrink to resize ldf files with switching to the simple recovery model, it breaks the LSN/log backup chain).  ldf growth is far more resource intensive than mdf files growth, the problem I see with Content db growth is the IT pro lets the ldf get out of control, then backs up and shrinks the database.  Usage causes the ldf to autogrow periodically and the farm goses back to needing the process repeated with heavy growth issues.  Key is to ensure the lfd has a decent initial size (you can work this out between full backup cycles), the ldf for content db’s should rarely need to autogrow and when it does make it a fixed amount.
  11. TempDB: Having multiple mdf tempdb files speeds up SQL performance.  The tempdb is a system db that has resource available to all users.  And from the expert
  12. TempDB: Increase it’s initial size  & autogrowth to MB as opposed to percent (see image2).
  13. TempDB: Simple recovery model for TempDB is correct.
  14. TempDB: The default is 1, you need more than this depending on how many CPU cores are on your database server.  1 option is set the number of TempDB’s to the same as the number of CPUI cores (1-to-1).  Some folks recommend the number of tempDB’s should be 1 less than the number of cpu cores, other folks go for 1 TempDB per 2 CPU cores.   I start with 4 and tune in performance testing or once it is running.  Saying that I normally have 16 cores.  I can’t see performance gains from my testing after 4 TempDB’s but as a rule I’d start with 1 TempDB for each 2 Cores and tune from there.
  15. TempDB: Move the tempdb.mdf files and the TempDB .ldf file to their own fast as possible drive.
  16. Content DBs: CA or PS when creating a new content db won’t take all the model settings, it does take initial sizes but not the autogrowth settings.
  17. Content DBs: Workaround- create the db outside of PS, get the SP collation right “Latin1_General_CI_AS_KS_WS” collation.
  18. If your SQL db uses spinning disk split the mdf and ldf files onto separate disks.  Order the db files as follows: tempdb must be on the fastest disk, content db log files next and content db’s next.
  19. Change the default backup location to a separate disk (pretty obvious but it is the default setting).
  20. Set the default for the database instance file locations  – set the default location where new mdf, ldf and backups will go on disk (per your fasteset disk calcs).
  21. Set the default for the database instance backup compression – I’d go with compression for all backups.
  22. mdf and ldf should be on separate drives for 2 reasons : IOPS speed (provided this is spinning disk) & DR (you don’t want to loose both).
  23. OS: NTFS allocation unit, by default on Windows 2008 this is 4096 byte (4kb), generally much faster to have it set to 64kb allocation unit size.  e.g. cmd>Chkdsk c:
  24. Use RAID 10 where possible.
  25. Windows firewall – if using it you will need to open the incoming SQL port i.e. 1433
  26. Avoid huge transaction logs and size them appropriately.  Pref don’t use simple recovery model. Ldf content is not removed every 60 seconds when it is written to the mdf files. Backup – get last full backup and last differential to get you to the lasted backup version. Or get the current ldf, restore the last full backup and play the current ldf through the db. To slim the ldf down, after a successful full backup, can backup the transaction with “truncate the transaction log” (it zeros all transaction before the checkpoint made by the transacion log backup or (sic. delete the log file) to get it back to a reasonable size.  Hint: BACKUP LOG databasename TO devicename
  27. Watch the size of the Content Databases, they take time to recover.  Max up to 4TB, try stick to around 200GB (exception will be for blob storage).  This makes backup and restore quick however AlwaysOn also changes the scenario.
  28. Format the Drives with 64K NTFS Allocation Units.
  29. Antivirus software must exclude LDF/MDF/NDF files.
  30. Don’t shrink database log files by switching the recovery model to Simple.
  31. Ensure you are within the latency recommendation for SP to SQL (< 20ms).
Image 1. Change the model database initial size and autogrowth settings.

Tip: AutoGrowth of SharePoint 2013 Content databases – Changing the initial size of the model db will affect the content db’s – nice, issues is that the autogrowth settings in the model db are not pushed to the content databases created through SharePoint (either CA or PowerShell).

Image 2. Change the TempDB to have multiple mdf files.
Image 3. Setting Memory on SQL Server instances.

SharePoint Sizing Starting point notes: SP_Config database – “Transaction log files. We recommend that you back up the transaction log for the configuration database regularly to force truncation.” Technet.   The Full recovery model is the default, switch this to Simple.  If you need Full, your ldfs be busy.  Suggest ldf at least 1000MB per day growth, can be a lot more.
Suggested Search database sizing.  If the Search databases are in the Full Recovery mode you also need to set the ldf sizing.

Database mdf mdf growth ldf ldf grow
SP_Search_Admin 100 MB 10 MB 100 MB 50 MB
SP_Search_CrawlStore 100 MB 50 MB 300 MB 100 MB
SP_Search_AnalyticsReportingStore 100 MB 50 MB 25 MB 25 MB
SP_Search_LinksStore 100 MB 50 MB 25 MB 25 MB

Update 23 Jan 2014:  Todd Klindt has a good set of blog posts on SQL 2012 for SharePoint 2013. How do ldf files work with mdf in SQL Server: Content goes into .ldf file temporarily, checkpoint occurs every minute and moves from .ldf to mdf.  If the “Full recovery model” is used the content in the the ldf file is retained. Hence large trans logs but recovery is better.  If a simple recovery model is used, the ldf data is dumped.
Keith Tuomi provide the code to automatically change the autogrowth sizing.

01 $Server=”SQLSRV2012″
02 [System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.SqlServer.SMO”) | out-null
03 $SMOserver = New-Object (‘Microsoft.SqlServer.Management.Smo.Server’) -argumentlist $Server
04 $databases = $SMOserver.Databases;
05 foreach ($DB in $databases | where{$_.Name -like ‘*Content*’}) {
06 #Set Log File growth
07 foreach ($DBLF in $DB.logfiles) {
08 $DBLF.set_GrowthType(“KB”);
09 $DBLF.set_Growth(“51200”); #50mb
10 $DBLF.Alter();
11 }
12 #set File Growth
13 $DBFG = $DB.FileGroups;
14 foreach ($DBF in $DBFG.Files) {
15 $DBF.set_GrowthType(“KB”);
16 $DBF.set_Growth(“102400”); #100mb
17 $DBF.Alter();
18 }
19 }

SQL Licencing: There are numerous licensing models available to SQL server on the different versions and I find them extremely complex. For large SQL using the Enterprise Edition of SQL 2012, per-core licensing at the hardware (hypervisor) level is an option. The SQL instances can be tied to specific hardware. Affinity rules do need to be setup to prevent vMotion moving the VM to another hardware host.  In a HA situation using AOAG in a passive situation, the secondary SQL servers et al. will require licencing. SQL Installation:  I slipstream and automatically install SQL Server 2012.  The checklist below lists the SQL features you can install.  Determine your needs makes creating the config.ini files used by the install much easier to do.  The example below is used to create both my primary SQL Server and the secondary (AOAG) server, they are identical.  The choices are pretty standard, you may want to move the Reporting Services features to another server or remove if you are not using them.

 Feature  Install
Database Engine Services Y
SQL Server Replication Y
Full-Text Search N
Data Quality Service N
Analysis Services N
Reporting Services: Native N
Reporting Services: SharePoint Y
Reporting Services Add in for SharePoint Y
Data Quality Client N
SQL Server Data Tools N
Integration Services Y
Client Tools Connectivity Y
Client Tools Backward Compatibility Y
Client Tools SDK N
Documentation Components N
Management Tools Basic Y
Management Tools Complete Y
SQL Client Connectivity SDK N
Master Data Services N
Distributed Replay Controller N
Distributed Replay Client N

More Info: http://yalla.itgroove.net/2013/03/sql-server-powershell-sharepoint-set-autogrowth-on-content-dbs/ http://blog.cloudshare.com/2013/08/28/how-to-use-the-same-autogrowth-value-for-sharepoint-content-databases/ http://technet.microsoft.com/en-us/library/hh292622.aspx http://channel9.msdn.com/Series/Tuning-SQL-Server-2012-for-SharePoint-2013/Tuning-SQL-Server-2012-for-SharePoint-2013-03-Server-Settings-for-SQL-Server (Excellent) http://www.sqlskills.com/blogs/paul/a-sql-server-dba-myth-a-day-1230-tempdb-should-always-have-one-data-file-per-processor-core/ http://www.brentozar.com/blitz/blitz-result-percent-growth-use/ http://www.brentozar.com/archive/2008/03/sql-server-2005-setup-checklist-part-1-before-the-install/ http://www.sqlskills.com/blogs/kimberly/8-steps-to-better-transaction-log-throughput/ http://www.toddklindt.com/default.aspx SharePoint database types and description
Thanks to: @allanSQLIS – Allan Mitchell – great sitting next to a SQL expert.
Steve Goodyear has a blog post on Farm Install and build guide.  I haven’t used it but it is a good post to check you are ready for your install and you have done the big steps.
SQL Hardening: From http://blogs.technet.com/b/rycampbe/archive/2013/10/14/securing-sharepoint-harden-sql-server-in-sharepoint-environments.aspx Hardening SQL Server is done in a 3 phased approach:

  1. Encryption at Rest (Encrypt the data sitting on the hard drives)
  2. Encrypt Connections (Encrypt the data in flight on the network between servers)
  3. Server Isolation (Configure SQL Server’s firewall to ignore requests from unauthorized servers)

Transparent Data Encryption (TDE) can be used to encrypt any SharePoint database.  This will encrypt the mdf and ldf files, this ensures that even is the hard disk storage is comprimised, the mdf and ldf cannot be used to restore the databases using the SQL restore tools.  There are a lot of ramifications to using TDE so review the decision to use TDE carefulkly before implementing.

Lots of good blogs are gone so I am Reblogging  it from:  http://blog.sharepointsite.co.uk/2013/10/sql-server-2012-for-sharepoint-2013.html