SQL restore backup to another database

Start MS SQL Management
Klik op de database, tasks, restore
Het kan zijn dat het restoren van de database niet lukt en dat je een melding krijgt dat je de db niet ‘alleen’ geopend hebt.
Laat de backupjob staan of als je deze na voornoemde foutmelding weggeklikt hebt weer helemaal klaar en vlak voordat je de backup wil restoren de volgende scripts uit

1)
select d.name, d.dbid, spid, login_time, nt_domain, nt_username, loginame
from sysprocesses p inner join sysdatabases d on p.dbid = d.dbid
where d.name = ‘DBNAME’
go

2)
kill <nr of SPID>

3)
Exec sp_dboption ‘DBNAME’, ‘single user’, ‘FALSE’
go
Tip: Disable de (service)-account in AD/SQL

Na het restoren staat als het goed is de db tegelijk weer in multi_user mode. Zo niet dan dit eerst doen via Options (van die database).
Daarna in SQL de files de naam (logical name) nog aanpassen naar de goede naam en je bent klaar.
Als goede informatie voor een restore job kun je de volgende pagina gebruiken. Nog een goede pagina is deze.

SQL SPN errors

In elevated prompt op SQL server uitvoeren:

setspn -A MSSQLSvc/<upn-servername>:1433 domain.name\service.account

results:

registering ServicePrincipalNames for

CN=service_account,OU=XX,OU=YY,DC=doman,DC=name MSSQLSvc\<upn-servername<:1433 Updated object

Troubleshooting SCCM

Integrating SCCM and MDT 2008[/b]
For our deployments, we always install MDT 2008 on our SCCM server and select Configure ConfigMgr Integration from the MDT area on the start menu. This gives us:

Templated task sequences we can import into SCCM
Additional TS Variables for use in our task sequences
Additional options and flexibility around computer backup, USMT etc.

For beginners, the template task sequences are a very quick way to get up and running while being guided through the process, while for more advanced users the additional functionality comes in handy when your task sequences become more complex.

[b]Setting yourself up[/b]
In order to have any chance at troubleshooting SCCM OSD issues, you need to do the following:

1

Install trace32.exe which is part of the SMS 2003 Toolkit 2
(download from Here)

2

Enable command line support within your boot images:
a.  Go to the properties of your boot image(s) (right click and choose Properties)
b.  Go to the Windows PE tab and tick the Enable command support (testing only) option.
c.  When prompted, click on Yes to update your distribution points.
d.  From within your boot image (Windows PE) environment, you can now press F8 to
open up a command window — very useful for troubleshooting

3

Be familiar with your OS setup log files (e.g. WindowsXP has setupapi.log, netsetup.log etc.)[b]Log files[/b]
The root of all Task Sequence troubleshooting is called smsts.log — and this log is always the first step to troubleshooting any TS issue — if you have an issue, look in here first!

Unfortunately, the smsts.log can be stored in one of 7 locations, depending on the stage of the build and the architecture of the OS:

WindowsPE, before HDD format:
x:\windows\temp\smstslog\smsts.log
WindowsPE, after HDD format:
x:\smstslog\smsts.log and copied to c:\_SMSTaskSequence\Logs\Smstslog\smsts.log
Full version windows, before SCCM agent installed:
c:\_SMSTaskSequence\Logs\Smstslog\smsts.log
Full version windows, after SCCM agent installed:
c:\windows\system32\ccm\logs\Smstslog\smsts.log
Full version x64 windows, after SCCM agent installed:
c:\windows\sysWOW64\ccm\logs\Smstslog\smsts.log
After Task Sequence has finished running
c:\windows\system32\ccm\logs\smsts.log
After Task Sequence has finished running(x64)
c:\windows\sysWOW64\ccm\logs\smsts.log

Information is also logged as SCCM client events, which can be viewed by running the SCCM report:
Last 1000 messages for a specific computer (Errors, warnings and information)

As a general rule, the SMSTS.log provides more detail, however the SCCM client events are easier to read, and, for simple issues, can lead you to the root cause very quickly.

[b]PXE boot issues[/b]
In order to resolve PXE boot issues, there are two main log files we are interested in:

Pxecontrol.log — which is located in the installation logs directory (eg C:\Program Files (x86)\Microsoft Configuration Manager\Logs\pxecontrol.log)
Smspxe.log — which is located in MP logs directory (eg C:\Program Files (x86)\SMS_CCM\Logs\smspxe.log)
If this is the first time you’ve setup a PXE service point, I recommend you check pxecontrol.log, there should be lines similar to the following:

address to server list 192.168.00.117  $$<SMS_PXE_SERVICE_POINT><Fri Jul 31 07:54:45.248 2009 Cen. Australia Standard Time><thread=772 (0x304)>
adding address to server list 127.00.00.01  $$<SMS_PXE_SERVICE_POINT><Fri Jul 31 07:54:45.250 2009 Cen. Australia Standard Time><thread=772 (0x304)>
Sending availiability packet to: 192.168.0.117~  $$<SMS_PXE_SERVICE_POINT><Fri Jul 31 07:54:45.252 2009 Cen. Australia Standard Time><thread=772 (0x304)>
Sent 274 bytes to 192.168.000.117:4011~  $$<SMS_PXE_SERVICE_POINT><Fri Jul 31 07:54:45.253 2009 Cen. Australia Standard Time><thread=772 (0x304)>
PXE test request succeeded.~  $$<SMS_PXE_SERVICE_POINT><Fri Jul 31 07:54:45.355 2009 Cen. Australia Standard Time><thread=772 (0x304)>
Successfully performed availability check against local computer.~  $$<SMS_PXE_SERVICE_POINT><Fri Jul 31 07:54:45.357 2009 Cen. Australia Standard Time><thread=772 (0x304)>

If you see otherwise, then, WDS or the PXE service point is not correctly installed.  Without going into too much detail in this area, as a catch-all fix:

Uninstall the pxe service point
Uninstall WDS
Reboot
Install WDS, but DO NOT configure
Install the pxe service point
Re-check the pxecontrol.log

Another very common error is to see the following when trying to PXE boot:

PXE-T01: The specified file was not found
PXE-E3B:TFTP error -- File not found

The x64 boot image has not been added to the PXE service point.
“But I’m only deploying an x86  boot image and OS,” I hear you say.  It doesn’t matter.  If the machine is x64 architecture (which all today’s new machines are), the boot ROM requested will be x64. This in no way effects your ability to use an x86 boot image; this boot ROM process is completely independent.The solution is to add the x64 image to your PXE DP and update. You will then see the directory \remoteinstall\smsboot\x64 populated with files, and your good to go.

Bron: klik hier

SQL Browser lijstje met Instances of servers schonen

Als je op een SQL server meerdere instances en databases hebt dan is het lastig als er een belangrijke instance verwijderd is en dat die toch steeds in dat lijstje blijft staan. Dat kan eenvoudig opgelost worden door het bestand SQLStudio.bin uit de map “%appdata%\Local\Microsoft\Microsoft SQL Server\100\Tools\Shell” te verwijderen. Let op! Je bent wel alles kwijt, maar als je gaat browsen zie je ook echt alleen de nog aanwezige instances.

Remove all Domain policies from unjoined computer

Run CMD as Administrator and run “del C:\Windows\security\database\secedit.sdb”

After deleting the security database you have also to delete some registry settings. Be carefull!

Run in the same cmd “Regedit” and go to HKLM, Software, Microsoft, Windows, Current Version and delete the key Group Policy

after that type in gpupdate /force /boot

Your computer should now be cleared of all domain policies.