Skip to main content

SQL Saturday #371 Tampa - I'm speaking!

I'll be speaking at SQL Saturday #371 in Tampa on February 28, 2015.

 If you are interested in minimizing or possibly preventing the type of breach that happened at Anthem Inc, you will likely find my session "Real World SQL Server Database Administration with just a bit of sysadmin" very interesting. 

 It is becoming increasingly difficult to allow SQL Server database administrators to retain perpetual sysadmin access on production servers due to IT Security, Audit, and Compliance concerns. 

 I will review the fundamentals needed to define a configurable permission model currently in use at a large insurance company that allows database administrators to do routine work without having unfettered access to business data. Several demonstrations will show that many DBA tasks can be done without sysadmin access. Attendees will also learn how to deploy a set of permissions that allows DBAs to do routine work, elevate DBA permissions quickly to respond to production emergencies and how to grant sysadmin permissions during disaster recovery scenarios. Scripts will be reviewed and demonstrated that secure the database server, undo the permission model in case of unforeseen circumstances and discover which servers remain to be locked down. Attendees will leave this session with the realization that DBAs need to be sysadmin only when required.

 SQL Saturday is a FREE training event for SQL Server professionals and those wanting to learn about SQL Server. SQL Saturdays are possible because of PASS, our sponsors, and the many volunteer speakers and staff that run the event. I encourage you to check the schedule. 

 I guarantee you will learn something new by the end of the day!

Comments

Post a Comment

Popular posts from this blog

Modifying Endpoint URLs on Availability Group Replicas

I recently had to modify the Endpoint URLs on our SQL Server Availability Group replicas.  The reason for this blog post is that I could not answer the following questions: Do I need to suspend data movement prior to making this change?  Would this change require a restart of the database instance? I spent enough time searching on my own to no avail that I tossed the question to the #sqlhelp hashtag on Twitter and Slack but didn't get an answer prior to executing the change request. After reading the relevant documentation, I think it's probably a good idea to suspend data movement for this change. The T-SQL is straightforward.  USE MASTER GO ALTER AVAILABILITY GROUP [AG1]  MODIFY REPLICA ON 'SQL2012-1' WITH (ENDPOINT_URL = 'TCP://10.10.10.1:5022'); ALTER AVAILABILITY GROUP [AG1]  MODIFY REPLICA ON 'SQL2012-2' WITH (ENDPOINT_URL = 'TCP://10.10.10.2:5022'); ALTER AVAILABILITY GROUP [AG2]  MODIFY REPLICA ON 'SQL2012-1
Post a Comment
Read more

Set Azure App Service Platform Configuration to 64 bit.

If you need to update several Azure App Services' Configuration to change the Platform setting from 32 bit to 64 bit under Configuration | General settings, this script will save you about six clicks per service and you won't forget to press the SAVE button. Ask me I know. 🙄 Login-AzureRmAccount Set-AzureRmContext  -SubscriptionName  "Your Subscription" $ResourceGroupName  =  'RG1' ,  'RG2', 'RG3' foreach  ( $g   in   $ResourceGroupName ) {       # Set PROD slot to use 64 bit Platform Setting      Get-AzureRmWebApp  -ResourceGroupName  $g  | Select Name |  %  {  Set-AzureRmWebApp  -ResourceGroupName  $g  -Name  $_ .Name  -Use32BitWorkerProcess  $false  }       # Set staging slot to use 64 bit Platform setting      Get-AzureRmWebApp  -ResourceGroupName  $g  | Select Name |  %  {  Set-AzureRmWebAppSlot  -ResourceGroupName  $g  -Name  $_ .Name  -Slot  "staging"  -Use32BitWorkerProcess  $false  }  }
Post a Comment
Read more

Azure Portal CPU Graph Bug or Feature?

I support an Azure PaaS application. We had a brief outage recently. Given that the code had not been changed in a month, we suspected some maintenance in an Azure data center stepped on our application. Ping tests and self-tests failed for approximately 10 minutes. The outage resolved on its own without intervention. I submitted a ticket to Azure Support to determine the cause of the outage but the reason I'm writing this post is because of the behavior I observed with the CPU graphs for Cloud Services while investigating the outage. The CPU graphs show different results depending on the time range selected. I would expect to see the CPU spike with the same value no matter what time range I selected. But, to see the spike that fired the alert, I had to to "Edit" the chart and select different time ranges to see the differences. It wasn't until I selected a narrow custom time range that the CPU graph would display the CPU spike that corresponded to the a
Post a Comment
Read more