Checking for the “Default” username

You can check for the presence of this login by running the query below. If found, a full network audit is recommended.

--Verify the default account doesn't exist.  No results is a good thing.
SELECT 
	[name],
	[type_desc],
	is_disabled,
	create_date,
	modify_date
FROM sys.server_principals
WHERE [name] = 'Default'

What if you already had a login named “Default”? Determine if the password was recently changed to “@fg125kjnhn987” and if there have been any recent login failures. Review for any recently created logins as well. Are all logins accounted for? Were any created that you were not aware of? If so, review each further to determine what permissions they have and identify what they’re being used for.

--Review recently created logins
SELECT 
	[name],
	[type_desc],
	is_disabled,
	create_date,
	modify_date
FROM sys.server_principals
ORDER BY create_date desc

Review recently modified logins.

--Review recently modified logins
SELECT 
	[name],
	[type_desc],
	is_disabled,
	create_date,
	modify_date
FROM sys.server_principals
ORDER BY modify_date desc

Avoid making your SQL Servers easy targets

By utilizing security best practices, most brute-force attacks can be stopped. Or, at the very least, set off alarm bells and whistles to alert you of suspicious activity. Below is a list of do’s and don’ts we typically recommend. This is not an exhaustive list.

Don’t

1. Don’t expose your SQL Servers to the internet (if at all possible). Use a VPN to access externally.
2. Don’t use weak passwords (for any account).
3. Don’t add your SQL Server service accounts to the local admin group.
4. Don’t grant your SQL Server service accounts more permissions than required.
5. Don’t grant logins more permissions than required.
6. Don’t install additional services which are not required. SQL Server licenses include not only the database engine, but integration services, analysis services, and reporting services as well (at the time of this post). It’s easy enough to go ahead and install these additional services but also increases the attack surface area. Only install what is required.
7. Don’t enable additional options, within SQL Server, if unneeded. For example, xp_cmdshell, Ole Automation Procedures, and ad hoc distributed queries.

Do

1. Patch often. Review latest cumulative update, service pack releases, and hotfixes. Start here.
2. Implement a policy in which an account will become locked out after X number of attempts.
3. Change passwords often.
4. Audit the creation of new logins (and review the audits often 😉).
5. Disable the SA account. This account is well known and has unfettered access.
6. If not required, don’t use SQL Server authentication.
7. Review failed login attempts. Especially those occurring numerous times within a short span of time. This could be an indication of a brute-force attempt.
8. Implement a process to audit using guidelines such as the US government Security Technical Implementation Guides (STIGs) or Center for Internet Security (more on these below).
9. Review the health and performance metrics of your SQL Servers regularly.
10. Proactively monitor your SQL Servers to look for unexpected deviations of resource consumption.

Audit your environment

These types of exploits can typically be avoided. Implementing good security practices can be a painful process (not only from a technical perspective but also from the staff and end user perspective). The following guides provide a large set of information and scripts to get you started with securing your environment.

CIS – Center for Internet Security

CIS Benchmarks are consensus-developed secure configuration guidelines for hardening. There are benchmarks for operating systems, server software, cloud providers, network devices etc. Take a look here for a list of what they have to offer. SQL Server specific benchmarks can be found at https://www.cisecurity.org/benchmark/microsoft_sql_server/. There are some aspects of the site which requires membership but includes additional tools. Well worth the consideration.

National Vulnerability Database

The NCP is the U.S. government repository of publicly available security checklists which provide guidance on setting the security configuration of operating systems and applications. The checklists (STIG) can be downloaded as a zip. To view, download and install the STIG Viewer from https://public.cyber.mil/stigs/srg-stig-tools/ and follow the instructions.

How we can help

Security is constantly evolving. Setting up good policies around platform hardening, password complexity and rotation, and using accounts with the least privilege required is a daunting task for any organization. Especially those without dedicated security or database administrators. I’m hopeful a few of the resources above can get you started on the right path. We’re here to help as well. If you’d like assistance in assessing your SQL Servers, schedule a call with us here.

Thanks for reading!

The post Am I affected by MrbMiner malware? appeared first on The SERO Group.

Requirements

The following requirements are needed. More information on how to setup a domain controller in Azure can be found here.

1. Visual Studio Code – Not a requirement, but provides intellisense for Azure CLI. The following extensions were installed as well.
   1. Azure Account
   2. Azure CLI Tools
2. Azure account
3. Resource group
4. Virtual Network
5. Virtual machine as the domain controller
6. Storage account which can be used as the cloud witness for the FCI
7. Two Azure VMs running Windows Server 2019
8. Azure availability set
9. Proximity group

We’ll assume the resource group, virtual network, domain controller, and storage account (to be used as the cloud witness), are already in place within a region which currently supports premium shared disks. Check here for a list of regions which currently support premium shared disks. You’ll also need to request access to try premium shared disks. (https://aka.ms/AzureSharedDiskGASignUp)

Proximity placement group

My demo virtual network and domain controller currently reside within the West Central US region. Placing the clustered virtual machines within a proximity placement group achieves the lowest possible latency between the two. This is a logical grouping to make sure Azure compute resources are located close to each other. For more information, see here.

After logging into your account, using Azure CLI (https://bit.ly/3ib2I2F) and setting your subscription using “az account set”, create the proximity group.

az ppg create --name SERO_FCI_PPG --location westcentralus --type standard --resource-group SERO_FCI_RG --tags "Purpose=FCI Demo"

Availability Set

Next, we need to create an availability set. An availability set is a logical group in Azure to ensure VM resources are isolated from each other and utilize separate physical servers, compute racks, storage units, and network switches. By using an availability set and FCI, we can ensure one node will be online during typical maintenance, such as patching, and reduce impact of single points of failure. However, an availability set does not provide data center redundancy. For more information, see here and here. The script below creates an availability set which uses 1 platform fault domain and 1 platform update domain.

az vm availability-set create --name SERO_FCI_AvailabilitySet --resource-group SERO_FCI_RG --location westcentralus --platform-fault-domain-count 1  --platform-update-domain-count 1 --tags "Purpose=FCI Demo" --ppg SERO_FCI_PPG

Virtual Machines

With the proximity group and availability set in place, we’re now ready to create our virtual machines. I’m using the Standard_D2s_v3 VM size and a few variables to avoid repeating them for each vm creation script. You could use a loop here as well. Be sure to update the values to match your environment.

availabilityset="SERO_FCI_AvailabilitySet"
adminusername="yourAdminUserName"
resourcegroup="SERO_FCI_RG"
imagevar="Win2019Datacenter"
vnetname="SERO_FCI_WESTCENTRALUS_NETWORK"
subnetvar="Internal"
sizevar="Standard_D2s_v3"
tagvar="Purpose=FCI Demo"
proximitygroup="SERO_FCI_PPG"
az vm create --name SEROFC1 --admin-username $adminusername --resource-group $resourcegroup --image $imagevar --vnet-name $vnetname --nsg '' \
--subnet $subnetvar --size $sizevar --tags $tagvar --availability-set $availabilityset --public-ip-address '' --ppg $proximitygroup
az vm create --name SEROFC2 --admin-username $adminusername --resource-group $resourcegroup --image $imagevar --vnet-name $vnetname --nsg '' \
--subnet $subnetvar --size $sizevar --tags $tagvar --availability-set $availabilityset --public-ip-address '' --ppg $proximitygroup

Add VMs to your domain

At this stage, go ahead and add the virtual machines to the domain and apply the latest updates. If your network restricts port access between machines on the same network, you may need to adjust your network security groups and the windows firewall. For this demo, I’ve disabled the windows firewall (disclaimer: not best practice and should be avoided in a real world scenario).

Create the premium shared disk

Now the exciting part :). Save the following json and modify to match your environment and the size of disk you wish to use. I saved the file as ShardDiskConfig.json.

{ 
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "dataDiskName": {
      "type": "string",
      "defaultValue": "SEROFCI_SharedDisk"
    },
    "dataDiskSizeGB": {
      "type": "int",
      "defaultValue": 256
    },
    "maxShares": {
      "type": "int",
      "defaultValue": 2
    }
  },
  "resources": [
    {
      "type": "Microsoft.Compute/disks",
      "name": "[parameters('dataDiskName')]",
      "location": "[resourceGroup().location]",
      "apiVersion": "2019-07-01",
      "sku": {
        "name": "Premium_LRS"
      },
      "properties": {
        "creationData": {
          "createOption": "Empty"
        },
        "diskSizeGB": "[parameters('dataDiskSizeGB')]",
        "maxShares": "[parameters('maxShares')]"
      }
    }
  ] 
}

Next, create the shared disk using the “az deployment group create” command and the config saved within the json file.

az deployment group create --resource-group SERO_FCI_RG --template-file /Users/lukecampbell/OneDrive/Lab/SharedDiskConfig.json

Attaching the shared disk

Next, we’ll need to attach the newly created shared disk to both of the virtual machines. Modify the values below to match your environment.

resourcegroup="SERO_FCI_RG"
location="westcentralus"
proximitygroup="SERO_FCI_PPG"
diskId=$(az disk show -g $resourcegroup -n SEROFCI_SharedDisk --query 'id' -o tsv)

az vm disk attach --resource-group $resourcegroup --vm-name SEROFC1 --name $diskId 
az vm disk attach --resource-group $resourcegroup --vm-name SEROFC2 --name $diskId 

Format shared disk

Now we’ll need to initialize the attached disk as a GPT partition and format using NTFS. This can be done using the Azure CLI or Powershell commandlets. I opted to remote into each VM and format using the disk management utility. No need to assign a drive letter at this step.

Create the failover cluster

We’re ready to create the failover cluster. If you’re familiar with creating clusters on premises, this is no different. However, since we’re setting up a SQL Server 2016 FCI, we’ll need to create a Azure internal load balancer (ILB) to hold the IP address of the virtual network name in which the SQL Server instance listens on. I won’t cover the cluster creation in detail here but the following is a summary of the steps required:

1. Install the failover cluster feature and management tools on both VMs.
2. Create the cluster
3. Add the shared disk to the cluster. I’ve assigned drive letter F to this disk.

One important note. The cluster will be created using a Distributed Network Name by default. SQL Server 2016 does not support DNN access points. By using the powershell statement below, you can create the cluster and a virtual network name instead.

New-Cluster -Name <FailoverCluster-Name> -Node ("<node1>","<node2>") –StaticAddress <n.n.n.n> -NoStorage -ManagementPointNetworkType Singleton

The new switch, ManagementPointNetworkType, allows you to specify either of the following values:

• Singleton: Use the traditional method of DHCP or static IP address.
• Distributed: Use a Distributed Network Name using node IP addresses.
• Automatic: Use detection. If running in Azure, use Distributed; if running on-premises, use Singleton (the default).

SQL Server 2016 install

Install SQL Server 2016 using the failover cluster installation wizard on both VMs. Assign an IP address for the virtual network name. Again, these steps are the same as when creating a FCI on premises. Below is a screenshot of the end result for my installation.

Load balancer

At this point, you should have a fully functional FCI. However, you won’t be able to connect remotely yet. We need to configure an Azure Load Balancer to hold the IP address assigned to the virtual network name of the FCI. The load balancer will route traffic to the primary node in the FCI. These steps could be achieved using the Azure CLI if needed. I opted to use the Azure portal following the steps provided here and create a basic ILB.

1. Frontend IP configuration (IP Address should match the IP address of the FCI virtual network name).

2. Backend pool – Contains the virtual machines hosting the FCI.

3. Health probes

4. Load balancing rules

After the load balancer has been configured, be sure to modify and run the powershell script here. The probe port must match the port provided when creating the health probes for the ILB. In this example, we used port 59999. If you have any issues with failovers, check all firewalls (both windows and the network security group rules in Azure). The script below is what I used when creating the demo. This only needs to be executed on one of the cluster nodes. Once completed, take the FCI offline and online again for the settings to take effect.

$ClusterNetworkName = "Cluster Network 1"
$IPResourceName = "SQL IP Address 1 (SQLSERVERFC1)" 
$ILBIP = "10.3.1.10" 
[int]$ProbePort = 59999

Import-Module FailoverClusters

Get-ClusterResource $IPResourceName | Set-ClusterParameter -Multiple @{"Address"="$ILBIP";"ProbePort"=$ProbePort;"SubnetMask"="255.255.255.255";"Network"="$ClusterNetworkName"
;"EnableDhcp"=0}

Connecting to the FCI

I verified connectivity to the FCI by installing SQL Server Management Studio on a third VM.

Failover to test connectivity.

Conclusion

I’m excited to see shared disks as an available option in Azure. We’ll build on this series next week by creating a SQL Server 2019 FCI and utilize the new distributed network name feature vs the load balancer. Let us know your thoughts regarding this option for high availability and if it’s something you may be interested in leveraging in the future.

Thanks for reading!

The post Azure shared disks – Failover Clustered Instance – SQL Server 2016 appeared first on The SERO Group.

Why should I care about shared disks?

Azure shared disk enable the ability to utilize FCIs and reduce storage consumption. Previously, if you created an FCI instance and didn’t want to use a file share, storage spaces direct was required and doubled the amount of space needed. Another option was to set up Availability Groups. Again, doubling the space and possibly requiring Enterprise editions of SQL Server (prior to basic availability groups being introduced). If you’re needing to migrate to Azure, and utilize IaaS vs PaaS and retain high availability, this is a great addition to the array of available options. Plus, unless you specifically need Enterprise edition features, you may be able to keep Standard edition further reducing costs.

What type of disks do I need to use?

Shared disks are currently available on two disk types; ultra and premium. Each type has there own list of limitations. Rather than listing those here, and the information becoming out of date, review the following links for the most up to date information;

1. Using Azure Ultra Disks
2. Premium SSDs

Which regions are shared disks currently available in?

Shared ultra disks are available within all regions which currently support ultra disks. See here for the latest list of regions. Premium shared disks are available in the regions listed here. If you’re using premium shared disks, you’ll need to request access using the form located at https://microsoft.qualtrics.com/jfe/form/SV_cMCj3LBlv47M6xL.

How do I get started?

This is an exciting option for those looking to migrate on-premises failover clustered instances to Azure with little modification. To get started, review Microsoft’s latest announcement, and the links provided above, to determine if this is the right option. We’ll be creating additional posts over the next few weeks detailing how to setup two node clusters using Windows Server 2019, SQL Server 2016, and SQL Server 2019. There are some major differences when using SQL Server 2016 and SQL Server 2019 which will be explained throughout the posts. SQL Server 2016 FCIs requires the use of an Azure load balancer and we’ll provide examples of a complete setup. SQL Server 2019 CU2 introduces a new feature, distributed network name, which further simplifies setup. You can read more on this feature here.

How can we help?

We’d be more than happy to discuss your move to Azure FCIs or any upcoming migration projects. Contact us here to schedule a call.

Be sure to check back soon! Better yet, go ahead and subscribe to get notified when new posts are available 😄.

Thanks!

The post Azure shared disks – Failover Clustered Instances appeared first on The SERO Group.

Distributed Network Name access point

In SQL Server 2019 CU2 (or later) failover clustered instances, the listener was enhanced to work with the Windows Server Failover Cluster DNN access points. Prior to supporting DNN access points, a virtual IP access point was used but wasn’t supported in Azure without creating a load balancer. DNN access points reduce the complexity of FCIs in Azure by allowing the SQL client to connect without the need for a load balancer.

Create the cluster and failover clustered instance

Creating the cluster, using Azure Shared Disks, was covered in our previous post here. The difference is that we’re installing a SQL Server 2019 FCI and then applying CU 7 to ensure distributed network names are supported. Go ahead and create your Windows failover cluster and then create the SQL Server 2019 FCI. You won’t be able to connect to the FCI instance just yet because we’re not setting up an Azure load balancer. Failover the clustered role to all nodes within the cluster just to ensure there’s no issues.

Create the DNN

After the FCI has been created, we’ll need to rename the virtual network name resource. However, this isn’t required if you’re planning to use a different name for the DNN and access the instance using a different DNS name than you specified when setting up the FCI. I renamed mine to SEROSQLFC_VNN (shown below). To rename, right click on the Server Name resource in Failover Cluster Manager, and choose properties. I appended the existing name with “_VNN”. Don’t delete this resource as it is a required component of the FCI infastructure.

Next, create the DNN. I’ll be using SEROSQLFC to access the instance and used the powershell script below to create it.

Add-ClusterResource -Name SEROSQLFC_DNN -ResourceType "Distributed Network Name" -Group "SQL Server (MSSQLSERVER)"

Get-ClusterResource -Name SEROSQLFC_DNN | Set-ClusterParameter -Name DnsName -Value SEROSQLFC

Once created, you should see a new resource within the cluster role.

Bring the DNN online. The instance must be restarted before accessing. I typically failover to the other node, attempt to access the instance from a remote server using SSMS, and then failback to ensure the instance can be accessed when hosted on either node.

IP conflicts and how to avoid them

When using a distributed network name access point there’s no longer a load balancer reserving virtual IP address in Azure and there’s a risk that another resource on the virtual network will be assigned the same IP address as the virtual IP address used by the FCI. This can lead to an IP conflict. The powershell script below was used to create an APIPA address to avoid this issue. Another option is to create a dedicated network adapter in Azure and reserve the IP address used by the virtual IP address resource. Both of these options can be seen here.

Retrieve the virtual IP resource name by opening Failover Cluster Manager and right clicking on the IP address resource (example below). Choose properties and note the resource name.

Get-ClusterResource "SQL IP Address 1 (SEROSQLFC)" | Set-ClusterParameter –Multiple @{"Address”=”169.254.1.1”;”SubnetMask”=”255.255.0.0”;"OverrideAddressMatch"=1;”EnableDhcp”=0}

Take the IP Address resource offline and back online for the changes to take effect. This will also take SQL Server offline so these resources will need to be restarted as well.

Additional resources for Creating Failover Clustered Instances

Distributed network names and shared disks simplify the usage of FCIs in Azure. However, there a few issues to watch out for. This post is not meant to provide an in depth review but a quick overview of what is possible using these new features available in Azure, Windows OS (since 2016), and SQL Server 2019 (cu2 or later). The resources below provide additional detail on the use of DNNs.

FCI DNN & SQL Server features

Rename a SQL Server Failover Cluster Instance

Create DNN for FCI

Conclusion

Let us know your thoughts regarding this option for high availability and if it’s something you may be interested in leveraging in the future.

Thanks for reading!

The post How to Create SQL Server 2019 Failover Clustered Instances in Azure appeared first on The SERO Group.

Many of the books I read so that I can grow professionally. Books on developing better leadership skills, on becoming more effective in what I do, on fostering deeper and stronger relationships within teams, and on how businesses can make better use of their data, are some of the topics that interest me.

Already this year, I’ve read three books that I’ve added to my Recommended Reading list. These were insightful, yet entertaining, applicable, yet engaging.

It’s Your Ship The United States Navy doesn’t have a monopoly on the highly-regimented, top-down leadership style. In fact, many companies still have this corporate culture. In It’s Your Ship, Abrashoff recounts how he was able to take a below average ship and turn it into one of the best ships in the Navy. His crew developed a sense of ownership and pride in their work. His bosses recognized Benfold’s accomplishments and rewarded the crew with additional liberty and flexibility. Abrashoff’s approaches work in the corporate world as well. This book is a must-read for leaders.

Permission to Screw Up Many business and leadership books are sanitized and polished. The authors share their successes without revealing the many painful mistakes and setbacks that plagued them along the way. This is not one of those books. In her book, Permission to Screw Up, Hadeed shares how she inadvertently started and grew a business hiring only millennials. She tells her engaging and personal story in an entertaining and thought-provoking way. In the end, the leadership lessons she shares seem more real and less academic, more applicable and less theoretical, more heartfelt and less boastful. Entertaining and informative, this book will help you build a better team.

The Like Switch: An Ex-FBI Agent’s Guide to Influencing, Attracting, and Winning People Over Jack Shafer spent years with the FBI, preparing spies for their missions and helping to recruit spies from other countries. During his career, he developed strategies for reading people, building trust, and developing long-term relationships. This is not a book about deceitfully manipulating people. This book shares how to build better and stronger relationships.

If you are or desire to be a leader in your organization, I’d highly recommend that you pick up a copy of these three books. They are well worth your time.

The full Recommended Reading list is here.

Enjoy!

The post Three New Books on the Recommended Reading List appeared first on The SERO Group.

A man and his wife were taking a lazy Sunday afternoon drive through the country enjoying the sights, sounds, and smells of the rural community. As they slowly navigated the narrow two-lane road, large hardwood trees reached for the sky and offered shade from the hot sun above, broad pastures and farmland extended as far as the eye could see, and picturesque oak barns dotted the landscape.

On the side of one of the barns, a series of targets was painted. There must have been a couple of dozen little red, yellow, and blue targets. In the center of each one was an arrow, a perfect bullseye. There were no other holes in the target; just one solitary bullseye.

The man slowed their car to get a better look. “That’s remarkable,” the man said to his wife.

“Maybe he was in the Olympics,” she replied.

Just then a little boy, perhaps eight or nine years old, opened the door of the white farmhouse nearby. He waved from the porch.

Curious, the man pulled into to gravel driveway and stopped the car.

“That’s some shooting,” the man said nodding toward the barn.

“Eh, it’s nothing really,” the boy demurred.

Thinking the boy jealous of his older brother, the man said “Well, I guess whoever shot those arrows must be pretty pleased with it.”

“Not especially,” the boy replied.

“Why would you say,” the wife asked.

“Those are my arrows,” the boy shrugged.

The man and wife glanced at one another. “Yours,” the both said skeptically.

“Sure. Want to see me shoot another one?”

Before they could answer, the boy disappeared into his house and returned a moment later with a bow, an arrow, a paint brush, and three small cans of paint – one red, one blue, and one yellow. They followed the boy to the barn.

The boy set his gear down about fifty feet from the barn, picked up his bow and notched an arrow. In one fluid motion, he slowly raised the bow, pulled the string back, and steadied his aim. A moment later the arrow released into the air and stuck with a dull thud into the side of the barn.

The boy carefully laid the bow down, picked up the paintbrush and paint cans, walked to the barn, and started painting a target around the arrow.

To Succeed, You Must Define Success

Unfortunately, many people are like the little boy in the story. They attempt to define success after the fact. They go through business or life somewhat aimlessly, being carried by the wind and whichever way it happens to be blowing at the moment. Then they try to make the best of it afterward, telling themselves and others that this is what they really wanted all along.

As leaders, our teams at work and our families at home, depend on us. It is our responsibility to define what success looks like. What is strategically important to us? Where should we spend our time and our resources? Where do we see ourselves in the future? More importantly, at our core, who are we and how do we see ourselves.

Tactically, what do we want to accomplish in the next week, in the next three months, in the next three years? How will we know that we’re making progress toward that goal? How will we know when we’ve achieved it?

Leaders must earn their leadership every day. Part of that is painting a vibrant picture of what success looks like and then creating an environment to accomplish it.

Are you earning your leadership?

The post What Is Success? appeared first on The SERO Group.

The answer to those questions and many similar ones are what Leigh Thompson, the author of The Truth About Negotiations, sets out to provide in this short, easy to read book.

In the introduction, Thompson states that she wants to do three things with the book. First, she strives to outline a game plan that will work in any negotiation. Whether your are negotiating a raise at work or attempting to overcome a difference with your neighbor, the basic premises of negotiations are the same.

Don’t underestimate how important opening offers are. Indeed negotiators’ first offers can generally predict the outcome of a negotiation….For these reasons your ideal offer should be close to the party’s barely-acceptable terms.

Second, she focuses on what she terms the “win-win goldmine”. It’s a simple concept that we’ve all known since kindergarten: it’s best when both parties walk away happy. Thompson provides techniques for asking questions that help you to get to the underlying interests of the other person so you can hopefully strike a deal you’ll both like.

Third she discusses how to handle less-than-ideal negotiation scenarios. Sometimes you must work with people you don’t trust, or who don’t trust you. That’s tough, but Thompson provides some key insight into ways to approach it.

While this isn’t a really deep dissertation on the subject, the 53 truths that Thompson shares provide a good overview to negotiations. I enjoyed reading the book and will hang on to it for future reference.

The post Book Review: The Truth About Negotiations appeared first on The SERO Group.

“In a hierarchy every employee tends to rise to his level of incompetence.” That’s the premise of Dr. Laurence Peter in his 1969 book, The Peter Principle: Why Things Always Go Wrong My first thought when I read a statement like that is: I wonder if Dr. Peter worked in a hierarchy and if so would his premise still apply?

Nevertheless. I think we’ve all seen instances where someone who is very good with technology is promoted and flounders. Horribly. And the worse they do, the more stress they feel. And they flounder even more. So what happens? The don’t make changes in their daily work required by the new position.

This is the first in an nine-part series on how to do your job better once you’ve been promoted. Hopefully the next eight posts in the series will help you to be aware of the new dynamics required by your new role so you adjust and excel.

Stop Doing Your Old Job

At first blush, this may sound too obvious to be worth mentioning. But there’s a reason it’s first on the list. This is far more prevalent than you may think.  If you don’t address this shortly after your promotion, it can set you up for failure down the road. [more…]

Employ the Same Successful Tactics

In your prior role, you approached your job, your responsibilities, and your preparation in a certain way, one that eventually led to your promotion. And while you don’t want to simply repeat the “what” you were doing before, you can most definitely leverage the “how” that got you the promotion. [more…]

Get to Know Your Peers

Far too often, IT professionals believe, mistakenly in my opinion, that they are paid to be good with technology. To be sure, that’s a part of it. In some jobs it may even be the majority of it. However, none us work in a vacuum and it’s important to know your colleagues before you need them. [more…]

Get a Trusted System

In your prior role, your may have had little difficulty managing your  workload and tasks. But now things are more complex. You are responsible for for work that you assign or delegate to others. You had better find a good system for managing that work.

Manage Your Email

Email is a great way to communicate, however when you receive scores or even hundreds of emails every day, it can quickly become unwieldy and detrimental to your productivity. A considerable portion of your day, or even night, can be consumed by email. You’ve got to find a good technique for managing your email inbox.

Manage Your Calendar

This could just as easily be called “Protect Your Time”. The collaborative world of shared calendars can be great for people who’s job it is to coordinate and plan meetings. However, for those of us who must attend meetings as well as doing work, shared calendars can be quite a disruption our days. You must take steps to ensure you have time to work.

Start Having Weekly One-on-Ones

As a new supervisor, team lead, manager, director, or even executive team member, it’s critical to build a trust with your team that can weather the storms that are sure to come. A great way to do this is to conduct a weekly, one-half hour, one-on-one meeting with each of member.

Recognize the Tendency to Revert

When push comes to shove and the pressure really begins to mount, many new managers tend revert back to their comfort zone, to their strengths, to what made them successful in their prior role. But that only makes matters worse. Being aware of this can help you to avoid it.

Questions:

• What were some of the unforeseen challenges that you faced after your last promotion?
• How did you cope with the new challenges?

The post “So I Got Promoted, Now What?” appeared first on The SERO Group.