CoreConfig Security Warning

Launching: "cscript Start_CoreConfig.wsf"

You'll be asked to confirm every operation

Security Warning
Run only scripts that you trust. While scripts from the Internet can be useful, this script can potentially harm your computer. Do you want to run C:\Utility\CoreConfig\CoreConfig.ps1?
[D] Do not run [R] Run once [S] Suspend [?] Help (default is "D"):




To solve this go to CoreConfig installation folder,edit Start_CoreConfig.wsf and substitute:



Function LaunchCoreConfig()
'========================
Dim iRetCode
Dim Temp
'
LaunchCoreConfig = False
'
On Error Resume Next
WshShell.RegWrite"HKLM\Software\Microsoft\Powershell\1\ShellIds
\Microsoft.PowerShell\ExecutionPolicy", "Unrestricted", "REG_SZ"
On Error goto 0
'
WshShell.CurrentDirectory = GlobalFolderPath
iRetCode = WshShell.Run ("C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe -WindowStyle Minimized -Sta -file CoreConfig.ps1", 1, True)
If iRetCode <> 0 Then
Call Debug("Error: During launch of CoreConfig! ReturnCode:" & iRetCode)
Call WshShell.Popup("Error: During launch of CoreConfig! ReturnCode:" & iRetCode & Vbcrlf & " Please copy source to local drive and try again!" ,0,"Error", 16)
Else
'Okay
LaunchCoreConfig = True
End If
End Function



with



Function LaunchCoreConfig()
'========================
Dim iRetCode
Dim Temp
'
LaunchCoreConfig = False
'

On Error goto 0
'
WshShell.CurrentDirectory = GlobalFolderPath
iRetCode = WshShell.Run ("%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe -executionpolicy bypass -WindowStyle Minimized -Sta -file CoreConfig.ps1", 1, True)
If iRetCode <> 0 Then
Call Debug("Error: During launch of CoreConfig! ReturnCode:" & iRetCode)
Call WshShell.Popup("Error: During launch of CoreConfig! ReturnCode:" & iRetCode & Vbcrlf & " Please copy source to local drive and try again!" ,0,"Error", 16)
Else
'Okay
LaunchCoreConfig = True
End If
End Function




Explanation:
First of all is not a good solution to set execution policy to unrestricted for all Powershell scripts changing Reg Key:
WshShell.RegWrite"HKLM\Software\Microsoft\Powershell\1\ShellIds\Microsoft.PowerShell\ExecutionPolicy", "Unrestricted", "REG_SZ"
Second this doesn't solve the problem.
The idea is to Bypass execution policy for this script... if we trust it, of course.
I do!
Now you can enjoy your CoreConfig

Abilitare un alias per un Fileserver Windows 2008 R2

Problema (tipico delle operazioni di consolidamento):
abbiamo un server con nome Server1 che deve rispondere anche alle richieste con il nome Server2, quindi sia come \\Server1 che \\Server2.

Da Windows 2008 in avanti i computer oltre a supportare SMB 1.0 supportano anche SMB 2.0. SMB è il protocollo che che supporta sia lato client che lato server la "Condivisione File e stampanti".

Quindi per abilitare l'alias SERVER2 dobbiamo:
1) Creare un CNAME (Alias) nel DNS server2.miodominio.local che punti a server1.miodominio.local
2) Abilitare il supporto per l'aliasing per il protocollo SMB 1.0:
Apriamo l'Editor di Registro (regedit) ed posizioniamoci su
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters

Aggiungiamo una nuova REG_DWORD:

Nome Valore: DisableStrictNameChecking
Tipo di dati : REG_DWORD
Base : Decimale
Valore : 1
3) Facciamo un reboot del server per fargli prendere le modifiche
4) Creaiamo un Alias per l' SMB 2.0:
Apriamo un prompt dei comandi con privilegi amministrativi:
setspn -a host/server2 server1
(dove server2 è l'alias netbios e server1 è il nome netbios originale del nostro server)
setspn -a host/server2.miodomino.local server1
(dove server2.miodomino.local è il FQDN dell'alias che vogliamo creare e server1 è il nome netbios originale del nostro server)

Adesso provate ad aprire \\server2 e dovreste accedere alle condivisioni

Coesistenza di IIS ed Apache sulla porta 80

La risposta più ovvia è che affiché i due servizi possano utlizzare la stessa porta bisogna metterli in ascolto su due IP diversi.
Quindi diciamo che vogliamo creare due endpoint:
1) APACHE: 192.168.1.1:80
2) IIS: 192.168.1.2:80

Per quanto riguarda Apache basta andare nell' httpd.conf e modificare la sezione:
LISTEN 80
in
LISTEN 192.168.1.1:80
(ovviamente controllando anche eventuali configurazioni al livello di singoli siti)
Si riavviano i servizi ed è tutto pronto.

Su IIS si va sui bindigs dei siti ed invece di selezionare tutti gli ip disponibili ossia 0.0.0.0 si seleziona esplicitamente l'IP 192.168.1.2.

E non va! :)

In effetti il nostro IIS si mette comunque in ascolto su 0.0.0.0:80 e quindi è in conflitto con l'incolpevole Apache.

Bisogna cambiare esplicitamente il listener HTTP.

Windows 2003 IIS6:
1) Scaricare httpcfg.exe dai support tool dal CD di installazione o da internet
2) Fermiamo i servizi IIS tramite il comando: net stop http /y
3) Fermare i servizi di Apache
4) Modifichiamo il listener: httpcfg set iplisten -i 192.168.1.2
5) Facciamo ripartire IIS: net start w3svc
6) Riavviamo Apache

Windows 2008 IIS7
Qui l'evoluzione del NETSH ci semplifica la vita
1) Apriamo un prompt dei comandi con privilegi amministrativi e diamo i seguenti comandi:
2) NETSH
3) HTTP
4) add iplisten ipaddress=192.168.0.2
5) EXIT

In ambedue i casi potete verificare tramite il comando:
NETSTAT -an
che il server è in ascolto correttamente su

192.168.1.1:80
192.168.1.2:80

Se trovate ancora 0.0.0.0:80
date il comando:
ISSRESET

Come fare: Backup Windows 2008 R2 Server Core

Come fare un backup di un Server Core Windows 2008 R2 senza usare strumenti di terze parti, ma sfruttando il backup integrato di Windows?
1) Installiamo la funzionalità di backup:
start /w ocsetup WindowsServerBackup
2) Eseguiamo il backup da riga di comando:
wbadmin start backup -allCritical -backupTarget:"\\Nome_Server\Backup_Folder"

Per approfondimenti sul comando WBADMIN

SQL Server 2008 Data Collector

Versione in italiano


Introduction

The typical problems of any DBA is to monitor the installation of its DB in terms of performance and server loads.
The process of preparing data collectors in order to do an analysis usually is a time-consuming and tricky task.
But if we are Database SQL Server 2008 lucky DBA, Microsoft has developed a tool that does the work for us: SQL data collector (not to be confused with Windows performace monitor  Data Collector).
In this way, the data collectors become a powerful ally of all DBAs, especially those less experienced.
Architecture

Although the architecture is quite complex

Data Collector Architecture: source MSDN

Installation is very simple because the configuration and parameterization is minimal, however, the data collector was designed to have extremely low overhead on the system when collecting and analyzing data.
It creates SSIS Package (SQL Server Integration Service)  launched by SQL Server Agent Jobs working to collect and store data in a Management Data WareHouse  (from henceforth MDW ) and finally the information is shown through a series of dynamic reports linked to each other that allow us to analyze in detail our SQL Server instances activities and trends. 

Installation

Open SSMS and go to the section of Management, right-click and select a data collector configuration data collectors

Then proceed with the MDW configuration

Choose where you want to create it and how to call it (I've imaginatively called it DataCollector).

CAUTION: The data warehouse DB can come to occupy up to 10GB of disk space!

So be careful where you position it and its initial and maximum size (if you want to set it)

Going forward we are asked to configure roles and permissions, but if you don't have any special need you can proceed without selecting anything. So  you complete this first configuration phase

Again we return to the Configuration

And this time we choose to set the data collection

and simply select the previous data warehouse and choose a directory in which park the data collected before they are placed in the MDW (see below: Query and System collectors collect data with a high frequency, but uploading to the Data Wharehouse is deferred in ways to avoid too much overhead due a nearly continuous data entry)

Even here we can proceed and complete the configuration

At this time our collectors are finally activated and slowly begin to populate our MDW

Data Collectors

After configuring our SSIS packages and their jobs are ready and running, you'll see the collectors  properties below that are shown only for explanatory purposes, those who were not interested in learning more can safely skip this paragraph.

How we can inferred in the previous images we have three types of collectors (4 in SQL 2008 R2):

1. Disk Usage
2. Query Statistics 
3. Server Activity

 Disk Usage: keeps track of  Database and Log files growth collecting information from a series of system tables and views.
Sampling is done every 6 hours and is loaded simultaneously on the MDW (given the low frequency). The data is kept for 730 days so as to allow adequate delineation of the growth trends.

Query statistics: collects data on SQL statements and their execution plans sampling every 10 seconds some Dynamic Management Views ( from now  DMV). MDW loading in this case is delayed and occurs every 15 minutes. Collected data is stored in the MDW for 14 days.

Server Activity: provides a view on the SQL Server activity, resources use and competition over resources, and also collects data on overall System resources allowing to identify any bottlenecks external respect than DB engine. In this case the data are collected by querying DMVs and SQL Sever and system performance counters.
Sampling occurs every 60 seconds and the data is uploaded every 15 minutes in  the MDW where they are kept for 14 days.

As can be seen from the images is possible, but absolutely  not necessary, change any parameter, such as data retention period in the MDW.

Reports

If you do not want to wait for the default schedules at any time you can force data collection and loading .

Collected data  analysis will put a strain on even a very experienced DBA, and for this reason that the second, and perhaps the greatest, advantage of the Data Collector are available reports.

As you can see reports are related one to one with collectors.
So let's see how our data are available and their graphical representation.
I apologize for the fact that all pictures are taken from a test environment virtually stationary, where the only load is the Data Collector, but this must not lead to the error of thinking that the tool creates a strong overhead on monitored systems.
 Disk Usage

Show all of our instance databases data and log files in terms of size and growth. Clicking on the name of the individual DB we can see free space and a list of all events related to their growth.

Query Statistics

First displays Queries Top 10 in relation to their resource consumption (default CPU) in a graphical format

and in textual form

Clicking on a single statement you can display details with valuable informations about resources use and the possibility of going into Waits details.

Server Activity:

This report displays the graphs for the four SQL tuning key resources. Very interesting is the fact that allows us to separate SQL Server from System activity.
It also puts in a graphical format, with the ability to go into detail with a single click, SQL Server Waits and the most significant activities in terms of SQL Server monitoring.

Conclusions and final notes


As we have seen this tool combines two great qualities: ease of configuration and power of analisys, so I'm sure that it will soon become part of almost all of your SQL Server installations.
Unfortunately, SQL Server 2005 does not support data collectors but MSSQLDUDE suggests us a technique to remedy the problem (to be honest I have never tried it)
Also remember that you can always export charts to PDF or Excel format.

Link:
Data Collector on MSDN
SQL Authority (where I stole some pictures)

Il Data Collector di SQL Server 2008

English Version

Introduzione 


Il tipico problema di ogni DBA è tenere sotto controllo le installazioni dei propri DB in termini di performance e carichi del server.
Il processo di preparazione di collettori di dati per poter fare analisi è normalmente un task laborioso e spinoso.
Ma se siamo dei fortunati DBA di Database SQL Server 2008, Microsoft ha predisposto uno strumento che fa il lavoro al nostro posto: i data collector per SQL (da non confondere con gli omonimi del performace monitor di Windows).
In questo modo i data collector diventano un potentissimo alleato di tutti i DBA, soprattutto di quelli meno esperti. 

Architettura

Nonostante l'architettura sia abbastanza complessa

Architettura dei DATA Collector: fonte MSDN

l'installazione risulta essere molto semplice in quanto la configurazione e la parametrizzazione è minima, peraltro il data collector è stato disegnato per avere un overhead molto basso sul sistema in fase di raccolta ed analisi dei dati.
Crea dei pacchetti SSIS (SQL Server Integration Service),  lanciati tramite dei JOB  e quindi  l'Agent di SQL Server, che si occupano di raccogliere e memorizzare i dati all'interno di un Data Ware House di gestione (Managemet Data WhareHouse da ora in poi MDW) ; infine rappresenta le informazioni raccolte tramite una serie di Report dinamici linkati tra di loro che ci consentono di analizzare a fondo l'attività ed i trend delle nostre istanze di SQL Server.

Installazione

Apriamo SSMS ed andiamo nella sezione di Gestione, tasto destro su data collector e selzioniamo configura data collector

poi procediamo con la configurazione del MDW:

 Scegliamo dove crearlo e come chiamarlo (io con molta fantasia l'ho chiamato DataCollector).

ATTENZIONE: a regime il Data WhareHouse può arrivare ad occupare fino a 10GB di spazio disco!

Quindi fate attenzione a dove lo posizionate ed alle dimensioni iniziali, incrementiali e massime (se proprio dovete impostarle)

Andando avanti ci viene chiesto di configurare i ruoli e le autorizzazioni, ma se non avete esigenze particolari potete semplicemnte procedere senza selezionare nulla andando completare la prima fase di configurazione

Nuovamente torniamo sulla configurazione

E questa volta scegliamo di impostare la collezione dei dati

e semplicemente selezioniamo il Data Wharehouse creato precendentemente ed una directory in cui parcheggiare i dati raccolti prima che vengano inseriti nel MDW (come vedremo più avanti  i collettori delle query e di sistema raccolgono dati con un'elevata frequenza, ma il caricamento nel DB di Data Wharehouse avviene in maniere differita per evitare un eccessivo overhead dovuto ad un quasi continuo inserimento di dati)   

 Anche qui possiamo procedere e completare la configurazione

A questo i nostri collettori sono finalmente attivati e pian piano il nostro MDW comincerà a popolarsi

I Data Collector

Finita la configurazione i nostri pacchetti SSIS ed i loro Job sono pronti e funzionanti; le proprietà dei collettori che vedrete di seguito sono visualizzate solo a scopo esplicativo, chi non fosse interessato ad approfondire può tranquillamente saltare questo paragrafo.

Come possiamo evincere nell'immagine precedente abbiamo tre tipologie di collettori (4 su SQL 2008 R2):

1. Utilizzo del disco
2. Statistiche sulle Query
3. Attività del Server

 Utilizzo del disco: mantiene traccia della crescita dei file di Database e di Log raccogliendo informazioni da una serie di tabelle e viste di sistema.
Il campionamento avviene ogni 6 ore e viene simultaneamente caricato sul MDW (vista la bassa frequenza). I dati vengono mantenuti per 730 giorni in maniera da consentire un adeguato delineamento dei trend di crescita.

Statistiche sulle Query: raccoglie dati sugli statement SQL ed i relativi piani di esecuzione campionando alla frequenza di 10 secondi alcune viste di gestione dinamica ( Dynamic Management Views, da ora in poi DMV). Il caricamento in questo caso è differito ed avviene ogni 15 minuti. I dati vengono conservati nel MDW per 14 giorni.

Attività del Server: fornisce una visualizzazione sull'attività, l'utilizzo di risorse e la competizione sulle risorse di SQL Server, raccoglie  inoltre dati generali sulle risorse di sistema per consetire l'identificazione di eventuali colli di bottiglia esterni rispetto al motore di DB.  In questo caso i dati vengono raccolti sia dalle DMV che da molti contatori di performance di SQL Sever e di sistema.
Il campionamento avviene ogni 60 secondi ed i dati vengono caricati sul MDW ogni 15 minuti dove vengono conservati per 14 giorni.

Come si evince dalle immagini è possibile, ma assolutamente non necessario, modificare alcuni parametri, come ad esempio il periodo di di ritenzione dei dati nel MDW.

I Report

Se non avete voglia di aspettare le schedulazioni predefinite potete in qualsiasi momento forzare la raccolta ed il caricamento dei dati.

L'analisi dei dati raccolti mettere a dura prova anche un DBA di grande esperienza, e per questo motivo che il secondo, e forse anche il più grande, vantaggio del Data Collector sono i report che mette a disposizione.

Come vedete i report sono in rapporto uno ad uno con i collettori.
Vediamo quindi i dati che ci vengono messi a disposizione e la loro rappresentazione grafica.
Mi scuso per il fatto che tutte le immagini sono prese da un ambiente di test praticamente fermo, in cui l'unico carico è quello del Data Collector, ma questo non deve assolutamente indurre nell'errore di pensare che lo strumento crei un forte overhead sul sistema monitorato. 

 Utilizzo del disco

Visualizza tutti i file di Dati e Log dei Database della nostra istanza in termini di grandezza e crescita. Cliccando sul nome del singolo DB possiamo vedere lo spazio libero e l'elenco di tutti gli eventi correlati alla loro crescita.

Statistiche sulle Query

Innanzitutto visualizza la TOP 10 delle Query relativamente al consumo di risorse (di default la CPU) in formato grafico

ed in forma testuale

Cliccando poi sul singolo statement si entra in una visualizzazione di dettaglio con preziosissime informazioni inerenti le risorse utilizzate e la possbilità di entrare nel dettaglio dei waits

Attività del Server:

questo report  consente di visualizzare dei grafici relativi alle quattro risorse fondamentali in fase di tuning di SQL. Molto interessante è il fatto che ci consente di separare l'attività SQL Server da quella di Sistema.

Inoltre mette in formato grafico, con la possibilità di entrare nel dettaglio tramite un semplice click sia i Wait che le attività più significative in termini di performance tuning del server SQL.

Conclusioni  e note finali


Come abbiamo visto questo strumento coniuga due grandi qualità: semplicità di configurazione e potenza di analisi, quindi sono certo che diventerà presto parte di quasi tutte le vostre installazioni di SQL Server.
Purtroppo SQL Server 2005 non supporta i data collector ma MSSQLDUDE  suggerisce una tecnica per ovviare al problema (ad onor del vero non l'ho mai provata).
Inoltre ricordate che potete sempre esportare i grafici in formato PDF o Excel.

Link:
Data Collector su MSDN
SQL Authority (a cui ho rubato un pò di immagini)

Trucco: CmdKey

Le connessioni verso un client o server che richiedono autenticazione hanno necessità di creare un contesto di autorizzazione.
Tipicamente ci viene richiesto di inserire Utente e Password, le credenziali immesse vengono memorizzate sul computer locale e riutilizzate automaticamente quando ci si connette nuovamente al compuer remoto.
Come gestire questo archivio?
Tramite l'utility a riga di comando cmdkey.exe.
Esempi:
cmdkey /list  -- fa una lista delle credenziali memorizzate

cmdkey /add:server01 /user:mikedan  -- usa l'utente mikedan per connetersi al server01

cmdkey /delete:server01  -- elimina le credenziali per connettersi al server01



http://technet.microsoft.com/en-us/library/cc754243(WS.10).aspx