I recently have had network issues at one of my customers sites with DHCP, this tool was very useful in the troubleshooting phase of resolving the problem.
http://blog.mir.net/2014/10/rogue-dhcp-server-detection-free-tool.html
Browser Not Supported RD Web Access / Server 2008 R2 Remote Desktop Services
If your trying to access a Microsoft Remote Desktop Services / RDS website from a Windows 8 machine or a pc with Internet Explorer 10 or 11 then you will see the error below :-
Browser Not Supported - This Web browser is not supported by RD Web Access. RD Web Access requires Internet Explorer 6.0 or later. You can download the latest version of Internet Explorer from the Windows Update Web site
This is caused by Microsoft not releasing an update to 2008 to allow it to be accessed in the later browsers. In order to get it to work we can implement a workaround that forces machines with newer browsers to access the site as IE9 compatability view.
First of all this fix ONLY works on RDS Gateway servers with 2008 R2 SP1 installed. If you try it on a server without SP1 it will get rid of the error but you wont see any remote apps.
1) Login to the RDS Gateway server
2) Open Up IIS Management Console.
3) Branch out the sites and then left click on RDweb. On the right hand side double click on HTTP Response Headers.
4) On the right hand pane now right click and select Add…
5) On the box that appears enter :-
Name : X-UA-Compatible
Value : IE=9
Now do a IISRESET on the server and you should be good to go..
UPDATE : If you have any pending windows updates also install these as sometimes it wont work until they are installed.
VMWare Network Performance Checks
If packets are not being dropped and the data receive rate is slow, the host is probably lacking the CPU resources required to handle the load. Check the number of virtual machines assigned to each physical NIC. If necessary, perform load balancing by moving virtual machines to different vSwitches or by adding more NICs to the host. You can also move virtual machines to another host or increase the host CPU or virtual machine CPU.
Verify that VMware Tools is installed on each virtual machine.
If possible, use vmxnet3 NIC drivers, which are available with VMware Tools. They are optimized for high performance.
If virtual machines running on the same ESX/ESXi host communicate with each other, connect them to the same vSwitch to avoid the cost of transferring packets over the physical network.
Assign each physical NIC to a port group and a vSwitch.
Use separate physical NICs to handle the different traffic streams, such as network packets generated by virtual machines, iSCSI protocols, VMotion tasks, and service console activities.
Ensure that the physical NIC capacity is large enough to handle the network traffic on that vSwitch. If the capacity is not enough, consider using a high-bandwidth physical NIC (10Gbps) or moving some virtual machines to a vSwitch with a lighter load or to a new vSwitch.
If packets are being dropped at the vSwitch port, increase the virtual network driver ring buffers where applicable.
Verify that the reported speed and duplex settings for the physical NIC match the hardware expectations and that the hardware is configured to run at its maximum capability. For example, verify that NICs with 1Gbps are not reset to 100Mbps because they are connected to an older switch.
Verify that all NICs are running in full duplex mode. Hardware connectivity issues might result in a NIC resetting itself to a lower speed or half duplex mode.
Use vNICs that are TSO-capable, and verify that TSO-Jumbo Frames are enabled where possible.
Overview of the different network adapters for your VMWare Guests
- Vlance: This is an emulated version of the AMD 79C970 PCnet32- LANCE NIC, and it is an older 10 Mbps NIC with drivers available in most 32-bit guest operating systems except Windows Vista and later. A virtual machine configured with this network adapter can use its network immediately.
- VMXNET: The VMXNET virtual network adapter has no physical counterpart. VMXNET is optimized for performance in a virtual machine. Because operating system vendors do not provide built-in drivers for this card, you must install VMware Tools to have a driver for the VMXNET network adapter available.
- Flexible: The Flexible network adapter identifies itself as a Vlance adapter when a virtual machine boots, but initializes itself and functions as either a Vlance or a VMXNET adapter, depending on which driver initializes it. With VMware Tools installed, the VMXNET driver changes the Vlance adapter to the higher performance VMXNET adapter.
- E1000: An emulated version of the Intel 82545EM Gigabit Ethernet NIC. A driver for this NIC is not included with all guest operating systems. Typically Linux versions 2.4.19 and later, Windows XP Professional x64 Edition and later, and Windows Server 2003 (32-bit) and later include the E1000 driver.
Note: E1000 does not support jumbo frames prior to ESXi/ESX 4.1.
- E1000e: This feature emulates a newer model of Intel Gigabit NIC (number 82574) in the virtual hardware. This is known as the “e1000e” vNIC. e1000e is available only on hardware version 8 (and newer) virtual machines in vSphere 5. It is the default vNIC for Windows 8 and newer (Windows) guest operating systems. For Linux guests, e1000e is not available from the UI (e1000, flexible vmxnet, enhanced vmxnet, and vmxnet3 are available for Linux).
- VMXNET 2 (Enhanced): The VMXNET 2 adapter is based on the VMXNET adapter but provides some high-performance features commonly used on modern networks, such as jumbo frames and hardware offloads. This virtual network adapter is available only for some guest operating systems on ESXi/ESX 3.5 and later. Because operating system vendors do not provide built-in drivers for this card, you must install VMware Tools to have a driver for the VMXNET 2 network adapter available.
VMXNET 2 is supported only for a limited set of guest operating systems.
To determine if the the VMXNET 2 (Enhanced) adapter is supported for your guest operating system and vSphere ESXi version, see the VMware Compatibility Guide.
Notes:- You can use enhanced VMXNET adapters with other versions of the Microsoft Windows 2003 operating system, but a workaround is required to enable the option in the VMware Infrastructure (VI) Client or vSphere Client. If Enhanced VMXNET is not offered as an option, see Enabling enhanced vmxnet adapters for Microsoft Windows Server 2003 (1007195).
- Jumbo frames are not supported in the Solaris Guest OS for VMXNET 2.
- VMXNET 3: The VMXNET 3 adapter is the next generation of a paravirtualized NIC designed for performance, and is not related to VMXNET or VMXNET 2. It offers all the features available in VMXNET 2, and adds several new features like multiqueue support (also known as Receive Side Scaling in Windows), IPv6 offloads, and MSI/MSI-X interrupt delivery. For information about the performance of VMXNET 3, see Performance Evaluation of VMXNET3 Virtual Network Device. Because operating system vendors do not provide built-in drivers for this card, you must install VMware Tools to have a driver for the VMXNET 3 network adapter available.
VMXNET 3 is supported only for virtual machines version 7 and later, with a limited set of guest operating systems.
To determine if the the VMXNET3 adapter is supported for your guest operating system and vSphere ESXi version, see the VMware Compatibility Guide. - Notes:
- In ESXi/ESX 4.1 and earlier releases, jumbo frames are not supported in the Solaris Guest OS for VMXNET 2 and VMXNET 3. The feature is supported starting with ESXi 5.0 for VMXNET 3 only. For more information, see Enabling Jumbo Frames on the Solaris guest operating system (2012445).
- Fault Tolerance is not supported on a virtual machine configured with a VMXNET 3 vNIC in vSphere 4.0, but is fully supported on vSphere 4.1.
- Windows Server 2012 is supported with e1000, e1000e, and VMXNET 3 on ESXi 5.0 Update 1 or higher.
How to bulk upload/copy files and folders to SharePoint
One of the biggest challenges I have when migrating customers over to SharePoint is moving their files and folders.
On the surface this is a daunting task as you can’t just give SharePoint your folder structure and tell it to do the work for you, so below are some of the processes I use.
Option 1: Manually via SharePoint Web Interface
Recreate the folder structure in SharePoint and upload the files via SharePoint in batches doing a multiple file upload to one destination folder at a time using explorer view. Not much fun for anyone, but it can be done. This has also proved to be unreliable, some machines need patching to get this to work, so I have found myself spending a lot of time correcting errors with the WebDAV service in order get this to work… This is my least favourite method.
Option 2: Commercial Tools
Possibly look at a third party tool they will cost you but will get the job done and probably with a few extra bell’s and whistles like applying metadata to SharePoint columns during the process. Some of the key companies to take a look at would be:
- Metalogix http://www.metalogix.net
- AvePoint http://www.avepoint.com
- Sharegate http://en.share-gate.com
- Thinkscape http://www.thinkscape.com
Option 3: Open Source Tools
There are some open source projects going around that claim to handle these types of bulk uploads, here’s a couple that look interesting:
https://spfilezilla.codeplex.com/ – This is my favourite – it really is just like FileZilla
http://spbulkdocumentimport.codeplex.com/
http://spfileupload.codeplex.com/
SharePoint Online, Sharing Content With External Users
The ability to invite external users to the Team site is enabled by default, so site owners and site collection administrators can share the Team site or any of its subsites with external users at any time. However, if you are the Office 365 admin, you can choose to disable the feature for all sites so that no future invitations can be sent. When this feature is deactivated, any external user currently invited to sites will no longer be able to access the sites.
Enabling external sharing is not the same thing as enabling anonymous access. When external sharing is enabled, users must be authenticated (by signing in) before they can access internal resources.
- Go to Admin > Service Settings > sites and document sharing.
- Do one of the following:
- Turn on external sharing
- Turn off external sharing
SECURITY
- When you deactivate external sharing, any external users who had access to the site at the time the feature was deactivated are denied access to the site and no future invitations can be sent. If the feature is reactivated with external user names in the SharePoint permissions groups, then those users will automatically be able to access the site again. To permanently prevent a user from accessing the SharePoint site, you can remove them from the list of external users.
- If external sharing is turned off globally, any shared guest links will also stop working. If the feature is later reactivated, these links will resume working. It is also possible to disable individual links that have been shared if you want to permanently revoke access to a specific document.
Remove individual external users
If you need to remove external users so that they no longer have access to sites that have been shared with them, you can do so by removing them from the list of external users in Office 365 Service Settings.
- Go to Admin > Service Settings > sites and document sharing.
- Click Remove individual external users.
- Select the external users you want to remove, and then click Delete (the trash can icon).
Connecting a MAC to SharePoint inc O365
A little over two years ago, I purchased my first MAC Book Pro and have not looked back since. Admittedly, the first thing I did was to install Windows as VM on it, but this was a case of having to because of my day job.
I have recently moved to PKF Cooper Parry LTD as a Infrastructure Consultant. One of my first projects is to migrate a small company’s data to O365 SharePoint. I will be delivering SharePoint training to end users next week, but have identified that the directors of the business all run from MACs.
One question to me in a planning meeting was…. Can I access SharePoint from my MAC? The answer is yes, and in some cases feels simpler to access your data than it does on a Windows PC.
Here’s how you connect your Mac with OSX to a SharePoint library — this requires Office for Mac 2011:
- From Spotlight look for “Microsoft Document Connection” and open it.
- Click on the “Add Location” button in the upper left and choose to “Connect to a SharePoint Site…”
- Press the Connect button.
Microsoft Document Connection, which was introduced in Office for Mac 2008 SP2 can connect to both SharePoint sites and OneDrive (not yet OneDrive for business). Multiple file upload is simple with this application – just drag and drop them into the application then everything is done. The application itself can be seen as a very lite version of SharePoint Workspace, although it doesn’t do much beyond upload, read, edit, check in/check out. You cannot delete a file, create a new folder, or edit its metadata properties in this app, and to get the latest update you need to hit Refresh button.
The TechNet document Plan browser support in SharePoint 2013 says that Safari is “Supported”. Unfortunately “Supported” does not mean that you will get full functionality. There are a hand full of features, that still only work with ActiveX (IE8/9 on Windows,Chrome/Firefox on Windows via plugins). These are important features like: presence information, Outlook integration (stssync), multiple file upload, and so on…)
Connect to Exchange Online using remote PowerShell
What do you need to know before you begin?
- You can use the following versions of Windows:
- Windows 8 or Windows 8.1
- Windows Server 2012 or Windows Server 2012 R2
- Windows 7 Service Pack 1 (SP1)*
- Windows Server 2008 R2 SP1*
* You need to install the Microsoft .NET Framework 4.5 or 4.5.1 and then either the Windows Management Framework 3.0 or the Windows Management Framework 4.0. For more information, see Installing the .NET Framework 4.5, 4.5.1 and Windows Management Framework 3.0 or Windows Management Framework 4.0.
- On your local computer, open Windows PowerShell and run the following command.
$UserCredential = Get-Credential
In the Windows PowerShell Credential Request dialog box, type your Exchange Online user name and password, and then click OK.
-
Run the following command.
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
Note If you are an Office 365 operated by 21Vianet customer in China, use the following value for the ConnectionUri parameter:
https://partner.outlook.cn/PowerShell. -
Run the following command.
Import-PSSession $Session
Note:
Be sure to disconnect the remote PowerShell session when you’re finished. If you close the Windows PowerShell window without disconnecting the session, you could use up all the remote PowerShell sessions available to you, and you’ll need to wait for the sessions to expire. To disconnect the remote PowerShell session, run the following command.
Remove-PSSession $Session
How do you know this worked?
After Step 3, the Exchange Online cmdlets are imported into your local Windows PowerShell session as tracked by a progress bar. If you don’t receive any errors, you connected successfully. A quick test is to run an Exchange Online cmdlet—for example, Get-Mailbox—and see the results.
If you receive errors, check the following requirements:
- A common problem is an incorrect password. Run the three steps again and pay close attention to the user name and password you enter in Step 1.
- To help prevent denial-of-service (DoS) attacks, you’re limited to three open remote PowerShell connections to your Exchange Online organization.
-
Windows PowerShell needs to be configured to run scripts. You only need to configure this setting once on your computer, not every time you connect. To enable Windows PowerShell to run signed scripts, run the following command in an elevated Windows PowerShell window (a Windows PowerShell window you opened by selecting Run as administrator).
Set-ExecutionPolicy RemoteSigned
- The account you use to connect to Exchange Online must be enabled for remote Shell. For more information, see Manage remote PowerShell access in Exchange Online.
- TCP port 80 traffic needs to be open between your local computer and Exchange Online. It’s probably open, but it’s something to consider if your organization has a restrictive Internet access policy.
Raspberry PI Goodness
Over the festive season, I was fortunate enough to acquire a Raspberry PI. I have never had the opportunity to play with one of these, I had to do a bit of research into what I needed to do to get this up and running.
To get all the software I needed I went to the following website where you can download all the required “NOOBS” (New Out Of the Box Software) you require.
http://www.raspberrypi.org/downloads/
Once the operation system had been installed I needed to work out how to get access to the PI remotely. The following are the steps I took in order to make this work.
1, Enabling the GUI
Assuming that you are using Raspbian, it is actually rather simple to do this. Simply open the terminal, and type in the following:
sudo raspi-config
The following window should show up
Navigate to
boot_behaviour and click enter. This should make it so that the GUI interface start automatically.2, Configuring a static IP address
A. Checking Set Up
Boot into Raspian and log in (Username. pi, Password. raspberry), this will all be command line stuff, so no need to log in to the GUI.
First, we need to list the network interface we currently have available:
cat /etc/network/interfaces
The line . . . .
iface eth0 inet dhcp
Implies that we’re currently getting out IP address via DHCP, meaning it’s being dynamically registered by the router. This is what we want to change!
B. Gathering Information
Fist of all we need to grab some information from our router and Pi. There’s a couple of command we need to run to get this info. Have a pen and paper handy! . . .
ifconfig
This reveals your router information, the bit you want is after eth0 (the ethernet connection). . . .
eth0 Link encap:Ethernet HWaddr b8:27:eb:b3:fc:2c
inet addr:192.168.1.81 Bcast:192.168.1.255 Mask:255.255.255.0
Write down the following information. . .
inet addr – 192.168.1.81 (Pi’s Current IP Address)
Bcast – 192.168.1.255 (The Broadcast IP Range)
Mask – 255.255.255.0 (Subnet Mask Address)
We need a little more information before we proceed. Use the command. . .
netstat -nr
(route -n will give you the same info.)
We need:
‘Gateway‘ Address – 192.168.1.254
‘Destination‘ Address – 192.168.1.0
C. Editing Network Configuration
We now need to plug this information into the Pi’s network configuration file using a text editor. I always use nano text editor. . .
sudo nano /etc/network/interfaces
Simply change the line that reads:
iface eth0 inet dhcp
to
iface eth0 inet static
Then directly below this line enter the following
address 192.168.1.81
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.254
To clarify what each part means. . . .
address – The address you want to give your Pi, this can be any IP in the network range, but it’s usually advisable to go higher rather than lower, or you could end up logging different devices to the same IP! I’ve selected 192.168.1.81, as we’re already registered to that address (denoted by ‘inet addr‘), but this can be any IP address from the range192.168.1.1 to 192.168.1.255.
netmask – The ‘Mask‘ address we wrote down earlier.
network – The router IP address, this is the ‘Destination‘ Address was found earlier. You can also grab this off your router, it will say on the side somewhere.
broadcast – The ‘Bcast‘ address we wrote down earlier.
gateway – This is the ‘Gateway‘ address we found earlier.
So, it should look something like the above, but with your values! Remember to save before exit, CTRL+X (exit) then yes to save changes!
D. Re-check Static IP Configuration
Then we’ll need to reboot and check your changes. . .
sudo reboot
Log back in and run
ifconfig
Which should reveal your new settings. .
To double checks all is working as it should, ping your ‘Gateway‘ Address. . .
ping 192.168.1.254 -c 10
(the -c 10 command simply denotes that you want to ping it 10 times, if you forget to add this, it will ping the address continuosly. To stop it press CTRL+C)
This should ping successfully and all packets should be received. If something’s not right double check through all your IP addresses, and make sure you’re pinging the right address too. Remember you can always revert back to DHCP by reversing the steps.
3, Installing PI Software
First you will need to install XRDP server on the Raspberry Pi:
sudo apt-get install xrdp
Once installed reboot your Raspberry Pi. The xrdp process will auto load and start when you boot the Raspberry Pi.
As with SSH, If you want to fiddle (not recommended), you can start and stop different services with the /etc/init.d files. There are a number of commands, start, stop, restart etc. To obtain a list, type:
/etc/init.d/xrdp
For example, to check the current status of ssh:
/etc/init.d/xrdp status
We can currently see that the xrdp service is running, however I’m disconnected.
How To Move AutoComplete Email Addresses In Outlook 2010/Outlook 2013
The following made it easy to transfer that autocomplete data to a new profile.
You would create and log in with a new profile, let’s call it “Personal Email”. This would create a blank new NK2 file called “Personal Email.NK2″. Then you could simply delete that NK2 file (I usually renamed it to Personal Email.OLD” – force of habit). Next, rename “Work Email.NK2″ to “Personal Email.NK2″. When you log into your new profile all your auto-complete data was there.
This all changed in Outlook 2013. Outlook 2013 did away with the NK2 file completely and merged all the autocomplete data into the users Exchange Mailbox/PST file. This was great in part as many people often forgot to transfer that NK2 file when they moved to a new computer, or, the autocomplete data was lost in the event of a catastrophic failure, such as a failure of the local hard drive.
What I found is that in some form autocomplete data does still exist in your local profile. On a Windows 7 box if you navigate to the RoamCache folder identified below:
C:\Users\\AppData\Local\Microsoft\Outlook\RoamCache
You may find one or more files called.
Stream_Autocomplete_.dat.
This is basically the new cache file for AutoComplete. The string of numbers is likely a SID of some form but where it is referenced (probably the registry) is beyond me.
All you need to do is identify what is the old autocomplete.dat file, normally by looking at the size of the file, the old one will be considerably bigger than the new one as it contains all of your cached addresses. Rename the old one to .old and copy the name before the .dat and rename your new one.
Step-By-Step: Creating a SQL Server 2012 AlwaysOn Availability Group
I recently found myself in a meeting discussing Clustering and High Availability Server platforms, and someone mentioned about an Always On Availability Group. This was new to me as I have not had experience of implementing a solution with this topology.
As soon as I had some spare time I did a little research and testing for myself, and I found the following article on Technet which I followed when setting up a SQL Server 2012 Always On Availability Group, below is a copy of that article:
One of the most talked about (and now frequently requested) feature in SQL Server 2012 is AlwaysOn Availability Groups. It brings SQL Server high availability and disaster recovery to a whole new level by allowing multiple copies of the database be highly available and potentially using them for read-only workloads and offloading management tasks such as backups. AlwaysOn Availability Groups allow you to fail over a group of databases as a single entity, unlike database mirroring where you can only do so one database at a time. This is very useful for applications that access multiple databases in a single SQL Server instance like SharePoint Server 2013. In fact, very recently, one of my customers had requested to configure SQL Server 2012 AlwaysOn Availability Groups for their SharePoint 2013 farm. I am also seeing more and more SharePoint 2013 farms leveraging on the SQL Server 2012 AlwaysOn Availability Groups for both high availability and disaster recovery.
This step-by-step has been created to help you get started in creating a SQL Server 2012 AlwaysOn Availability Group for your mission-critical databases.
Prerequisites
- Windows Server Failover Cluster (WSFC). AlwaysOn Availability Groups rely on the Windows Server Failover Cluster for failure detection and management of the Availability Group replicas. This is where a lot of customers get confused because of their previous knowledge of Microsoft Cluster Services (MSCS.) In previous versions of Windows Server, you need shared storage to create a failover cluster for the quorum disk. Windows Server 2008 and higher provided the option to use a file share witness as a quorum configuration. Therefore, you DO NOT need shared storage to create a Windows Server Failover Cluster for AlwaysOn Availability Groups. This, of course, does not change the requirement if you intend to use a SQL Server Failover Clustered Instance (FCI) as a replica in your Availability Group. For this step-by-step, we will only be working with standalone SQL Server 2012 default instances.
- Download SQL Server 2012 Enterprise Edition. AlwaysOn Availability Group is an Enterprise Edition feature. Before deciding to implement this feature, take stock of your SQL Server licenses to make sure you have enough to get you covered. If you intend to use the other replicas for read-only workloads or offloading your backups, you would need licenses for those SQL Server instances as well. This is also another one of those items that customers get confused with because in previous versions of SQL Server, database mirroring can be configured with Standard Edition.
- Same SQL Server collation for all replicas. I usually don’t recommend running databases with different collation requirements in the same SQL Server instance due to potential issues caused by applications using temporary tables. This is one of the reasons for keeping the database collation the same for a single instance (SharePoint 2013 also requires a specific collation for the content databases.) If you want to configure AlwaysOn Availability Groups for your databases, they should all be running the same collation on all of the SQL Server instances acting as replicas.
- Two to Five SQL Server Instances acting as replicas. SQL Server instances that will be used as a standby for high availability and/or disaster recovery are called replicas. Unlike database mirroring where you can only have one extra copy of the database, AlwaysOn Availability Groups allow you to have up to five copies of the database running on five replicas – three of which can be configured for synchronous-commit mode and two in asynchronous-commit mode.
Windows Failover Cluster Feature Installation
Since AlwaysOn Availability Groups require a Windows Server Failover Cluster, we first need to add the Windows Failover Cluster Feature to all the machines running the SQL Server instances that we will configure as replicas. For the operating system, we will be using Windows Server 2012. To add the Failover Clustering feature:
- Open the Server Manager console and select Add roles and features. This will launch the Add Roles Features Wizard
- Click Next until you reach the Select Features dialog box. Select the Failover Clustering checkbox. When prompted with the Add features that are required for Failover Clustering dialog box, clickAdd Features. Click Next.
- Click Install to install the Failover Clustering feature.
Windows Failover Clustering Configuration for SQL Server 2012 AlwaysOn Availability Groups
Prior to configuring the Windows Server Failover Cluster, it is assumed that you have the appropriate rights in Active Directory. For a complete listing of the different Active Directory permissions to create a Windows Server Failover Cluster, see Failover Cluster Step-by-Step Guide: Configuring Accounts in Active Directory. To configure Windows Failover Clustering,
- Launch Failover Cluster Manager from within the Server Manager console.
- Within Failover Cluster Manager, click the Validate Configuration… link.
- In the Validate a Configuration Wizard dialog box, click Next.
- In the Select Servers or a Cluster dialog box, add the server hostnames of the SQL Server instances that you want to configure as replicas in your Availability Group. Click Next.
- In the Testing Options dialog box, make sure that the option Run all tests (recommended) is selected. Click Next.
- In the Confirmation dialog box, click Next.
- In the Summary dialog box, click Finish to create the Windows Failover Cluster.
NOTE: The Failover Cluster Validation Wizard is expected to return several Warning messages, especially if you will not be using shared storage. As we mentioned earlier, there is no need to use shared storage to create the Windows Server Failover Cluster that we will use for our Availability Group. Just be aware of these Warning messages as we will configure a file share witness for our cluster quorum configuration. However, if you see any Error messages, you need to fix those first prior to creating the Windows Server Failover Cluster. - In the Access Point for Administering the Cluster dialog box, enter the virtual server name and virtual IP address of your Windows Server Failover Cluster.
- In the Confirmation dialog box, click Next. This will create the Windows Failover Cluster using the servers as nodes of the cluster, add DNS and Active Directory entries for the cluster hostname.
- In the Summary dialog box, verify that the configuration is successful.
- To configure the cluster quorum configuration to use a file share, right-click on the cluster name, selectMore Actions and click Configure Cluster Quorum Settings… We will be configuring a file share witness for our cluster quorum setting. By default, the wizard will configure the cluster to use Node Majority.
- Click Next.
- In the Select Quorum Configuration page, select the Add or change the quorum witness option. Click Next.
- In the Select Quorum Witness page, select the Configure a file share witness (recommended for special configuration) option. Click Next.
- In the Configure File Share Witness page, type path of the file share that you want to use in the File Share Path: text box. Click Next.
- In the Confirmation page, click Next.
- In the Summary page, click Finish.
Enable SQL Server 2012 AlwaysOn Availability Groups Feature
Once the Windows Server Failover Cluster has been created, we can now proceed with enabling the AlwaysOn Availability Groups feature in SQL Server 2012. This needs to be done on all of the SQL Server instances that you will configure as replicas in your Availability Group. To enable the SQL Server 2012 AlwaysOn Availability Groups feature,
- Open SQL Server Configuration Manager. Double-click the SQLServer (MSSQLSERVER) service to open the Properties dialog box.
- In the Properties dialog box, select the AlwaysOn High Availability tab. Check the Enable AlwaysOn Availability Groups check box. This will prompt you to restart the SQL Server service. Click OK.
- Restart the SQL Server service.
Create and Configure SQL Server 2012 AlwaysOn Availability Groups
Availability Groups can be created on existing databases or even a temporary one in preparation for application installation. If you intend to create an Availability Group for a new SharePoint 2013 farm, you will need to create a temporary database. This is so that the SharePoint 2013 farm will use the AlwaysOn Availability Group when creating the farm configuration and the admin content databases. After the SharePoint 2013 farm has been created, this database can be removed from the Availability Group configuration and deleted from the instance.
To create and configure a SQL Server 2012 AlwaysOn Availability Group,
- Open SQL Server Management Studio. Connect to the SQL Server instance
- In Object Exporer, expand the AlwaysOn High Availability folder. Right-click on the Availability Groups folder and select the New Availability Group Wizard… option. This will launch the New Availability Group Wizard.
- In the Introduction page, click Next.
- In the Specify Availability Group Name page, enter the name of the Availability Group in theAvailability group name: field. Click Next.
- In the Select Databases page, select the checkbox beside the database that you want to include in your Availability Group. The databases have to be in Full recovery model prior to joining them in the Availability group. Click Next.
- In the Specify Replicas page, under the Replicas tab, click the Add Replicas button and connect to the other SQL Server instances that you joined as nodes in your Windows Server Failover Cluster. Configure the following options
- Automatic Failover (Up to 2) : Checked
- Synchronous Commit (Up to 3) : Checked
- Readable Secondary: No
- In the Endpoints tab, verify that the port number value is 5022.
- In the Listener tab, select the Create an availability group listener option. Enter the following details.
- Listener DNS name: Name that you will use in your application connection string
- Port: 1433
- Click the Add… button to provide an IP address. In the Add IP Address dialog box, enter your preferred virtual IP address in the IPv4 Address field. Click OK. Click Next.
- In the Select Initial Data Synchronization page, select the Full option. Provide a shared folder that is accessible the replicas and that the SQL Server service account used by both replicas has Writepermissions to. This is just a temporary file share to store the database backups that will be used to initialize the databases in an Availability group. If you are dealing with large databases, it is recommended that you manually initialize the databases prior to configuring them as your network bandwidth may not be able to accommodate the size of the database backups. Click Next.
- In the Validation page, verify that all validation checks return successful results. Click Next.
- In the Summary page, verify all configuration settings and click Finish. This will create and configure the AlwaysOn Availability Group and join the databases.
- In the Results page, verify that all tasks have been completed successfully.
Congratulations! You have just created a SQL Server 2012 AlwaysOn Availability Groups. You can now use the Availability Groups listener name in your application connection string. Keep in mind that you need to manually add new databases in the Availability Group even though your application has already been using the listener name. So, be sure to monitor the replicas in your Availability Groups to be alerted when new databases are created.
Malcolm Plested IT Blogs 