Hi all,
On a large farm context, it appears to be common to have content databases pre-provisioned by the SQL DBA on the different disks reserved for farm data, due (among other causes) to the impossibility to specify mdf/ldf file location from theAdd-SPContentDatabase cmdlet. This way, it is possible to distribute accesses among disks according to the usage of the farm. So creating a content databse is a two-step process:
- Create the database at the SQL Server level, as a regular SQL database (specifying mdf/ldf paths, assign rights, etc.)
- Convert it into a sharepoint content database by running the Add-SPContentDatabase cmdlet and specifying that database.
This is perfect... unless you protect the SharePoint instance with DPM, and happen to protect also the rest of databases of the farm (search, usage, profiles...) with DPM's SQL autoprotection.
In this case, after creating the SQL database (and before you have the time to run the second step), DPM finds the new SQL database and adds it automatically to the SQL server autoprotection. You will probably fail to notice this, then attach the DB to SharePoint, and then find that your brand new database is being protected by the wrong protection group...
Have you ever faced this problem? how did you solve it? is there a way to override, or delay the SQL Server autoprotection? which is the mechanism that makes DPM be aware of new databases (something triggered just after db creation, or pure periodical scheduling?)
Regards
