18 Jul 2012

Move SQL database

http://msdn.microsoft.com/en-us/library/ms345408.aspx

HyperV tips

  • Never save state on a Domain Controller doing so can cause domain synchronisation issues.
  • Never pause a Domain Controller, this can cause replication issues.
  • Do not take Snapshots of Domain Controllers.
  • Use Fixed size disks, this will improve performance, and help reduce disk fragmentation.
  • Always defragment a physical disk before creating a virtual hard disk.
  • Be mindful of the integration services affect on a Domain Controller. If you provide the time synchronisation service to a Domain Controller, you can cause time synchronisation issues in your domain.
  • Don't expand the Virtual Hard Disk if you have snapshots which haven't merged with the main VHD. This will make it impossible to remerge them.
  • If you cannot merge your snapshot (avhd) files back into the main VHD. You can attempt to use WinImage (http://www.winimage.com) to retrieve the data from within the snapshot file. To do this simply rename the snapshot file from string.avhd to string.vhd then open with winimage.
  • Remember to uninstall the VM Additions before migrating Virtual Machines from Virtual PC or Virtual Server 2005 R2, otherwise you will receive the following error when you try to uninstall them from inside Hyper-V:
  • You can install Virtual Machine Additions only on a virtual machine that is running a supported guest operating system

Merge avhd to vhd in HyperV by manual

Hyper-V brings to life several additional disaster recovery scenarios that can be leveraged to our advantage when the need arises. One of the features that really comes into play are VM snapshots. A Snapshot is basically a spot in time where the current running configuration of the Virtual Machines is saved to a Snapshot Differencing Disk file (AVHD), from which you can return to from the future. This tip will show you how to manually merge hyper-v snapshots into a single VM for point in time restores.

When you create a differencing disk the original VHD is no longer modified and the snapshots are merged with the original vhd only when it is powered off. In disaster recovery scenarios, There may be cases where we want to manually merge snapshots ( avhd )

In order to do this, You must first change the extension of the Youngest AVHD file to VHD. 
Any VHD differencing disk(avhd) will always go to its parent, not the root parent.

So if you have a bunch of AVHDs, Each depends on the one before it - like the rungs of a ladder - they are sequential.  Most folks have a very simple linear chain of snapshots. Example : VHD - AVHD1 - AVHD2 - AVHD3 - AVHD4. ( Here AVHD4 is the Youngest and AVHD1 is the Oldest)

The parent of AVHD4 is AVHD3.  The parent of AVHD3 is AVHD2  The parent of AVHDn would simply be the one before it.

You need to Start Merge From Young AVHD to Old AVHD to complete the Merge Operation.

To Start Merge follow the below steps
  • First Identify the Youngest AVHD ( In Our Ex : AVHD4)
  1. Rename the Youngest AVHD (AVHD4)  to VHD ( Should not rename all the AVHDs at a time, Need to Rename only Youngest Avhd First) 
  2. You can choose the Edit Disk option from the Actions menu in the Hyper-V Management Console.
  3. Click Next through the first screen and select the snapshot file on the following screen.
  4. Select Merge on the next screen and choose the To parent virtual disk option and click Finish.
  5. After Successfully Completing Merge, Now Automatically AVHD4 will be deleted.
  • Now Rename the Second Youngest Avhd (AVHD3) to Vhd. and Repeats the Steps from 1 to 4 until Oldest AVHD ( AVHD1) Get Merge with Parent VHD.
Once this has completed you should create a new virtual machine with the default options you would normally use, selecting to use an existing virtual disk on the hard disk screen. You should select the newly merged VHD file.

Now you have Successfully Completed Manually Merge avhd to vhd in Hyper-V

http://social.technet.microsoft.com/wiki/contents/articles/6257.manually-merge-avhd-to-vhd-in-hyper-v.aspx

13 Jul 2012

Configure SQL Server 2008 for Sharepoint 2010 and Project Server 2010 installation

Configure SQL Network Settings for SQL Server 2008
To configure the network settings for SQL Server 2008 complete the following steps:
1. From the computer console click the Start button  >> All Programs  >> Microsoft SQL Server 2008 2.  2. Expand Configuration Tools and select SQL Server Configuration
The system displays the SQL Server Configuration Manager.
3. In the left pane, expand SQL Server Network Configuration, and then select the target SQL Server instance for your Project Server databases.
4. Verify that the TCP/IP option is enabled in the right frame.

Add a SQL Server Login for the Farm Administrator Account
 Project Server 2010 requires that the Farm Administrator Role Account have a SQL Server login with public, dbcerator, securityadmin and sysadmin roles in SQL Server. To create a SQL Server login and add the roles for the login, complete the following steps:
1.       Open SQL Server Management Studio.
2.         Connect to the database engine for your Project Server 2010 target instance
3.         Expand the Security node, then right-click on Logins and select the New Login option



4. The system displays the New Login dialog
5. Enter the domain account you created for the Farm Administrator in the Login Name field. From the Select a page list on the left, select Server Roles.

6. In the Server roles list, select the dbcreator, securityadmin, and sysadmin check boxes. The public roles checkbox is selected by default. Leave this setting selected.
7. Click the OK button to continue.


Enable the Common Language Runtime 
Enabling the Common Language Runtime (CLR) for SQL Server improves Project Server 2010 performance by 30% on average, according to Microsoft. To enable the common language runtime, click on the New Query button in the SQL Server Management Studio window and copy the following query into the SQL Query pane

sp_configure ‘clr enabled’, 1; 
go 
reconfigure; 
go





Click the Execute button to execute the query and enable the CLR. After executing the query the output section should report a success message like the one shown in Code Sample below. Note that the Query includes the RECONFIGURE statement, and it is not necessary to run this again.  

Configuration option 'clr enabled' changed from 0 to 1. Run the RECONFIGURE statement to install.  

Set SQL Server Database Collation 
Your SQL Server collation must be configured for case-insensitive. In a default English language version, the default collation (SQL_Latin1_General_CP1_CI_AS) is compliant with this requirement. If you are not working with a default English SQL Server installation, you may need to change your SQL Server database collation to case-insensitive, accent-sensitive, Kana-sensitive, and width-sensitive.

Prepare SQL Server Analysis Services for Project Server
You must complete two simple configuration steps to prepare your instance of SQL Server Analysis Services for Project Server 2010:
1) Add the Farm Administrator Role account to the OLAP Users Local Group on the server, and
2) Configure the Farm Administrator Role account permissions in SQL Server Analysis services. To add the Farm Administrator account to the OLAP Users Local Group, complete the following steps:  1. Log in to the computer running Analysis Services and select
Administrative Tools from the Start menu and select Computer Management from the submenu.
2. On the Computer Management page, in the left pane under System Tools, expand the Local Users and Groups item. Click to expand the Groups folder and locate the OLAP Users Local Group for your Analysis Services instance as shown for SQL Analysis Services 2008
3. Double-click on the group name to open the group Properties dialog

4. In the Properties dialog, click the Add button. The system displays the Select Users, Computers, or Groups dialog
5. In the Select Users, Computers, or Groups dialog, enter the name of your Farm Administrator account. You may click the Check Names button to verify your entry, or click the OK button to accept your entry. The account now appears in the Members section of the Group Properties dialog shown previously. Click the OK button to close the Group Properties dialog and then close the Computer Management page to continue.

To add the Farm Administrator as an Analysis Services server administrator complete the following steps: 
1. Open SQL Server Management Studio. In the Connect to Server window, select or browse to connect to the SQL Server Analysis Services instance for your Project Sever 2010 deployment.
2. In Microsoft SQL Server Management Studio Object Explorer, right-click on your SQL Server 2005 Analysis Services instance name, and then click Properties from the pop-up menu. The system displays the Analysis Services Properties dialog. From the Select a page pane, click the Security item. Your Analysis Server Properties dialog should look like the
3. Click the Add button. The system displays the Select Users or Groups dialog
4. On the Select Users or Groups dialog, type the name of the Farm Administrator account.
5. Click the OK button to add the Farm Administrator account to the Server Administrators list
6. Click the OK button on the Analysis Server Properties page to exit the operation.

11 Jul 2012

Managed Service Account–SQL Server 2012

As you know there are so many security measures are taken during every release of SQL Server. This version of SQL Server will be using Managed Service account to run SQL server related services. In other terms earlier versions we used Local system account as service account for all SQL Server related services however in this version we be will using individual local accounts for all SQL server related services. In this case whatever application runs on local system are allowed to access SQL Server. So to overcome this MS team has started using managed service accounts in SQL Server.

Let me give you a brief about Manage service account then we will discuss about the new changes related to service account in SQL Server 2012.

What is Managed Service Account?

Managed Service Account (MSA) is a new type of account that’s supported in Windows 7 & Windows 2008 R2. Main reason for this new account type is to isolate one service from another. In earlier operating systems we will run the services either in Localsystem or Domain accounts. Let’s assume you run SQL Server using Local system that means any other service running in Local system can connect to SQL Server and retrieve the data, this seems to be a loop hole when you run it in localsystem. We can use domain account to avoid this scenario however maintaining these domain accounts will take considerable time. In addition to this most of the organizations won’t change domain service account password in a period of time that means if someone knows the password he will be able to connect to SQL Server anytime as the password remains the same forever.
Considering all these things in mind they have added the new account feature in Windows 7 & Windows 2008 R2. Below are the advantages of Managed service account
  • Automatic password management. Password for MSA will be automatically changed every 30 days. However there is a known issue when the password gets changed it can cause a failed authentication attempt using old password, to overcome this you need to install a patch, refer KB article http://support.microsoft.com/kb/2494158 for more details.
  • SPN management is made simpler (domain need to be in Windows 2008 R2 functional level) for these accounts, which allows service administrators to set SPN’s for these accounts. For windows 2003 and windows 2008 functional level, you can update the schema to support this.
You can also create MSA for your own application service. Crucial part is that you don’t have a GUI to create \ configure a MSA for your service, you need to work with powershell cmdlets. For further information on MSA check the KB articles below
http://technet.microsoft.com/en-us/library/dd548356.aspx
http://technet.microsoft.com/en-us/library/ff641729%28v=ws.10%29.aspx

What’s added in SQL Server 2012

In earlier versions (from SQL 2005) of SQL Server, as part of Service account security standards they created local groups in the computer and granted necessary permission for the groups where ever applicable. However in SQL Server 2012 that’s not applicable, they will create individual managed service account for each SQL Server service. This means all SQL Server related services will run on their own service account there by isolating each services. You can see from the image below each service have different service account and each of these account have their own SID
service_account_sql_2012_1
Naming convention for the service accounts is as below
Service Name
Instance
Service Account Naming Convention
Database Engine Default MSSQLServer
Agent Service Default SQLSERVERAgent
Reporting Server Default ReportServer
Analysis Service Default MSSQLServerOLAPService
Fulltext Service Default MSSQLFDLauncher
Database Engine InstanceName MSSQL$InstanceName
Agent Service InstanceName SQLAgent$InstanceName
Reporting Server InstanceName ReportServer$InstanceName
Analysis Service InstanceName MSOLAP$InstanceName
Fulltext Service InstanceName MSSQLFDLauncher$InstanceName
Integration Service Not applicable MSDtsServer110
I have a curiosity to check admin permission associated to these accounts, I could see SA access granted only to SQL agent service account and not to database engine, that’s a classic example how they grant only required permission
service_account_sql_2012_2
Finally I’ve checked the administrators group in computer to check is any SQL related groups got created. Yes there are couple of groups still get created in computer for Browser service and analysis services. Analysis service account and browser service account are part of  analysis group & browser group respectively.
service_account_sql_2012_3
From the screenshot above it’s clear that analysis groups are created per instance. Thus MSA is a added security hardening step in SQL Server 2012 to isolate all SQL server related services, thus no more access using local system account.

9 Jul 2012

Dang ky BIS Mobifone

DK BASP gửi +999 để đăng kí gói BASIC PLUS (Tham khảo các gói khác http://blackberry.mobifone.com.vn/#/option)

-Sau khi đăng kí thành công thì tổng đài gửi SMS confirm "Quy khach da dang ky thanh cong goi BASP. Han su dung den ngay....... Xin cam on!."
-Soạn DATA ON gửi 999, chờ tổng đài xác nhận thành công thì khởi động lại máy.

-Khi thấy cụm từ EDGE ở gần cột sóng nhận được 1 message confirm BlackBerry Registration: "Your handheld has been registered with the wireless network".

-Vào phần “Host Routing Table” trong “Setting”, bấm nút “CHÙM DÂU” chọn “Register Now”.Tin nhắn thông báo đăng ký thành công, máy sẽ tự động cập nhật “Services Book”, cách dễ hơn là bạn có thể download những “Services Book” của MOBIFONE được chia sẽ trên các Diễn Đàn rồi cài vào máy.

-Thử vào mạng xem, nếu không được Trở ngược “Mobile Network Options” Ở mục “Data Services”, chọn “On” sau đó khổi động lại máy.

- Để kiểm tra dung lượng soạn KT DATA gởi 999,

- Để hủy, soạn HUY_Mã gói cước, gởi 999 . (trong bài là BASP, thì soạn HUY BASP gửi 999)

-Khi chuyển sang dùng điện thoại BlackBerry mới, chỉ cần gắn SIM cũ, BIS được kích hoạt. Vào trang web http://mobifone.blackberry.com chọn vào Change Device > Detect new device để xác nhận máy mới.

http://www.tinhte.vn/threads/1311966/

Windows update error code 80072EE2 of Windows 2008 R2 running on Hyper V

Windows 2008 R2 has installed on Hyper V without problem but when trying to do windows update I got an "Windows could not search for new updates, An error occurred while checking for new updates for your computer. Error(s) found: Code 80072EE2" error message


None of these suggestions helped solve the connection problem. Error 0x80072ee2 was displayed after all attempts except one that works on my case.

It's simply to disable Large Sent Offload IP4 on NIC that assigned for VM that has error.

Total Pageviews