The steup is based on setup pptp vpn.
Preshare key for Authentication -
Configure VPN1:
1. Routing and Remote Access -> Properties -> Security -> Allow custom IPSec policy for L2TP connection -> Preshare Key
2. Routing and Remote Access -> All Tasks -> Restart
Configure CLIENT1:
1. VPN Connection Properties -> Security -> Type of VPN (L2TP/IPSec) -> Advanced Settings -> Use Preshared Key for Authentication
2. Connect VPN
Certificate for Authentication -
Configure VPN1:
1. MMC -> Certificate -> Computer Account -> Local Computer
2. Certificate -> Personal -> All Tasks -> Request New Certificate
3. Next -> Certificate Enrollment -> Active Directory Enrollment Policy -> Computer -> Details -> Properties -> Private Key -> Key Options -> Make Private Key Exportable
4. Routing and Remote Access -> All Tasks -> Restart
Configure CLIENT1:
1. Export the VPN Computer (with private keys) and CA Root certificate and import in CLIENT1. MMC -> Certificate ...
2. VPN Properties -> Security -> Advanced Settings of L2TP/IPSec -> Use Certificate for Authentication
3. Connect VPN
SHOOT FOR THE SKY
Thursday, February 13, 2014
Setup PPTP VPN
Domain: contoso.com
DC1 - DC, DNS, DHCP
IP: 10.0.0.5/24
DNS: 10.0.0.5
VPN1 - VPN Server, DHCP Relay Agent
IP1: 10.0.0.14/24 (Internal)
DNS1: 10.0.0.5
DG1: N/A
IP2: 192.168.1.14/24 (Internet)
DNS2: N/A
DG2: 192.168.1.1
CLIENT1 - VPN Client
IP:192.168.1.13/24 (Internet)
DG: 192.168.1.1
Configure VPN1:
1. Join VPN1 to domain
2. Log on VPN1 with Domain Administrator
3. Add role Network Policy and Access Services -> Routing and Remote Access
4. Configure and Enable Routing and Remote Access
5. Remote Access (Dial-up or VPN) -> VPN
6. Select Internet Network Adapter
7. Automatically allocate IP for VPN clients
8. No, use Routing and Remote Access to authenticate connection requests
9. Routing and Remote Access -> DHCP Relay Agent -> Add 10.0.0.5 as DHCP server
10. Configure Routing and Remote Access -> Ports if necessary
Configure CLIENT1:
1. Network and Sharing Center -> Set up a new connection or network -> Connect to a workplace -> VPN -> Set up an Internet connection later -> Internet Address (192.168.1.14) -> User Name and Password
2. Log on DC1, enable the user remote access by Dial-in -> Allow Access
3. Connect VPN
DC1 - DC, DNS, DHCP
IP: 10.0.0.5/24
DNS: 10.0.0.5
VPN1 - VPN Server, DHCP Relay Agent
IP1: 10.0.0.14/24 (Internal)
DNS1: 10.0.0.5
DG1: N/A
IP2: 192.168.1.14/24 (Internet)
DNS2: N/A
DG2: 192.168.1.1
CLIENT1 - VPN Client
IP:192.168.1.13/24 (Internet)
DG: 192.168.1.1
Configure VPN1:
1. Join VPN1 to domain
2. Log on VPN1 with Domain Administrator
3. Add role Network Policy and Access Services -> Routing and Remote Access
4. Configure and Enable Routing and Remote Access
5. Remote Access (Dial-up or VPN) -> VPN
6. Select Internet Network Adapter
7. Automatically allocate IP for VPN clients
8. No, use Routing and Remote Access to authenticate connection requests
9. Routing and Remote Access -> DHCP Relay Agent -> Add 10.0.0.5 as DHCP server
10. Configure Routing and Remote Access -> Ports if necessary
Configure CLIENT1:
1. Network and Sharing Center -> Set up a new connection or network -> Connect to a workplace -> VPN -> Set up an Internet connection later -> Internet Address (192.168.1.14) -> User Name and Password
2. Log on DC1, enable the user remote access by Dial-in -> Allow Access
3. Connect VPN
Friday, February 7, 2014
Basic Cisco Switch Configuration
Switch# configure t
Switch(config)# hostname S1
S1(config)# line console 0
S1(config-line)# password letmein
S1(config-line)# login
S1(config-line)# exit
S1(config)# enable password pass
S1(config)# enable secret sec
S1(config)# service password-encryption
S1(config)# banner motd "This is a secure system. Authorized Access Only!!!"
S1(config)# exit
S1# show run
S1# copy running-config startup-config
S1# configure t
S1(config)# interface vlan 1
S1(config-if)# ip address 192.168.1.253 255.255.255.0
S1(config-if)# no shutdown
S1# copy running-config startup-config
S1# show ip interface brief
Switch(config)# hostname S1
S1(config)# line console 0
S1(config-line)# password letmein
S1(config-line)# login
S1(config-line)# exit
S1(config)# enable password pass
S1(config)# enable secret sec
S1(config)# service password-encryption
S1(config)# banner motd "This is a secure system. Authorized Access Only!!!"
S1(config)# exit
S1# show run
S1# copy running-config startup-config
S1# configure t
S1(config)# interface vlan 1
S1(config-if)# ip address 192.168.1.253 255.255.255.0
S1(config-if)# no shutdown
S1# copy running-config startup-config
S1# show ip interface brief
Monday, February 3, 2014
Don't revert to a snapshot on domain controller
You take a snapshot on your domain controller virtual machine. After that you make a few update to the domain, and each update or change increases the USN (Update Sequence Number). The information is replicated to other domain controllers in the forest and their metadata got updated accordingly.
Due to whatever reason, you find the domain controller unstable and would like to go back to the state of the snapshot. Hence, you click revert to snapshot button and expect everything goes fine again. Unfortunately, the USN goes back as well and it is much smaller that what other domain controllers expected, so they ignore the data and refuse to replicate the information with it.
This condition is known as USN rollback, and it leads to many unexpected issues, such as the one I posted. After I resolve the USN rollback issue, I can use Authentication type Reuse Session again without any problem. So the root cause is not patch or update of VMware but the USN rollback.
To fix USN rollback issue by following steps:
1. Remove Active Directory from the domain controller to force it to be a stand-alone server. (dcpromo.exe /forceremoval)
2. Shutdown the demoted server.
3. Clean up the metadata of the demoted domain controller on a healthy domain controller. (delete computer object in Active Directory Users and Computers, delete NTDS setting and server object in Active Directory Sites and Services)
4. Transfer or seize the FSMO roles to the healthy domain controller.
5. Start the demoted server.
6. Install Active Directory again on the server.
7. Configure the server to be a global catalog if it was one.
8. Transfer the FSMO back.
Refer to ref1 and ref2 for more detailed information.
The command you may need:
# netdom query fsmo
# repadmin /showrepl
# repadmin /showutdvec dc1 dc=abc,dc=com
Due to whatever reason, you find the domain controller unstable and would like to go back to the state of the snapshot. Hence, you click revert to snapshot button and expect everything goes fine again. Unfortunately, the USN goes back as well and it is much smaller that what other domain controllers expected, so they ignore the data and refuse to replicate the information with it.
This condition is known as USN rollback, and it leads to many unexpected issues, such as the one I posted. After I resolve the USN rollback issue, I can use Authentication type Reuse Session again without any problem. So the root cause is not patch or update of VMware but the USN rollback.
To fix USN rollback issue by following steps:
1. Remove Active Directory from the domain controller to force it to be a stand-alone server. (dcpromo.exe /forceremoval)
2. Shutdown the demoted server.
3. Clean up the metadata of the demoted domain controller on a healthy domain controller. (delete computer object in Active Directory Users and Computers, delete NTDS setting and server object in Active Directory Sites and Services)
4. Transfer or seize the FSMO roles to the healthy domain controller.
5. Start the demoted server.
6. Install Active Directory again on the server.
7. Configure the server to be a global catalog if it was one.
8. Transfer the FSMO back.
Refer to ref1 and ref2 for more detailed information.
The command you may need:
# netdom query fsmo
# repadmin /showrepl
# repadmin /showutdvec dc1 dc=abc,dc=com
Sunday, February 2, 2014
VMware vCenter Server 5.1U1 login fails with the error: A general system error occurred: Authorize Exception
I meet a VC login issue today with error message:
A general system error occurred: Authorize Exception.
As usual, the message is kind of useless... So after checked the log: C:\Program Files\VMware\Infrastructure\SSOServer\logs\ssoAdminServer.log, I found the error information that is more usefull:
Ok, login to web client through:
https://10.0.0.10:9443/vsphere-client/ admin@system-domain/xxxxxxxx
Then find Administration -> Sign-On and Discovery -> Configuration -> Edit the ActiveDirectory item. Change the Authentication Type from Reuse Session to Password. The issue got resolved.
A general system error occurred: Authorize Exception.
As usual, the message is kind of useless... So after checked the log: C:\Program Files\VMware\Infrastructure\SSOServer\logs\ssoAdminServer.log, I found the error information that is more usefull:
It should be a SSO identity source connection problem.[2014-02-03 06:32:31,479 ERROR opID=D9F02EFF-00000005-6e pool-13-thread-21 com.vmware.vim.sso.admin.vlsi.PrincipalDiscoveryServiceImpl] Error connecting to the identity sourcecom.rsa.common.ConnectionException: Error connecting to the identity source
Ok, login to web client through:
https://10.0.0.10:9443/vsphere-client/ admin@system-domain/xxxxxxxx
Then find Administration -> Sign-On and Discovery -> Configuration -> Edit the ActiveDirectory item. Change the Authentication Type from Reuse Session to Password. The issue got resolved.
But this way has a significant disadvantage. If you change your password, the SSO service could not connect to Active Directory anymore. In large AD environments it is often not allow to set the “Password never expires” property for a user. From security reasons the password must frequently changed. Therefore each time you change your password you have to alter the Identity Source Entry as well.
Hence “Reuse session” Authentication Type option is a better and actually the default option.
However, this looks like a fixed issue in 5.1U1b (1 AUG 2013 | Build 1235232), see kb. I don't want to update my infrastructure at this moment, so leave it for now.
VSS Full Backup vs VSS Copy Backup
Both create backup of all the files, and VSS Full Backup modify the archive bit while VSS Copy Backup leave it. So if VSS is the only backup you use, you should use VSS Full Backup since the second backup would be an incremental backup.
Imaging the situation you use VSS Full Backup with third-party backup software - the third-party backup software creates a backup on Monday, and you use VSS Full Backup to create a backup on Wednesday, then the third-party backup software creates a second backup on Friday, the second backup would only include the difference between Wednesday and Friday since VSS Full Backup clear the archive bit on Wednesday.
Hence, the backup behavior of the third-back is not expected. In summary, use VSS Copy Backup if VSS is not the only backup solution and use VSS to create full backup always and thrid-party backup in a combined (full + incremental) way.
Refer to diff of vss full backup and vss copy backup.
Refer to diff of vss full backup and vss copy backup.
VDAP vs VSS
Host Operating System Level Backup is simple so as virtual backup makes data protection easier for the user.
VMware's VADP (vStorage APIs for Data Protection) is technically superior to Microsoft's Hyper-V VSS(Volume Copy Shadow Service) because VADP supports Changed Block Tracking (CBT). On many file systems, CBT identifies the disk sectors altered between two change set IDs. On VMFS partitions, CBT can also identify all the disk sectors that are in use.
Virtual disk block changes are tracked from outside virtual machines, in the virtualization layer. When software performs a backup, it can request transmission of only the blocks that changed since the last backup, or the blocks in use. The CBT feature can be accessed by third-party applications as part of the vSphere APIs for Data Protection (VADP). Applications call VADP to request that the VMkernel return blocks of data that have changed on a virtual disk since the last backup snapshot.
VADP enables centralized, off-host LAN free backup of vSphere virtual machines, reduces ESX host resources to do backup processing, and enables flexible backup windows. A backup product using VADP can backup vSphere virtual machines from a central backup server or virtual machine without requiring backup agents or requiring backup processing to be done inside each guest virtual machine on the ESX host. This offloads backup processing from ESX hosts and reduces costs by allowing each ESX host to run more virtual machines.
VADP leverages the snapshot capabilities of VMware vStorage VMFS to enable backup across SAN without requiring downtime for virtual machines. As a result, backups can be performed non-disruptively at any time of the day without requiring extended backup windows and the downtime to applications and users associated with backup windows.
VSS, which operates at the block level of the file system, provides a backup infrastructure for Microsoft operating systems. The VSS requestor announces that it needs to create a server snapshot. Prior to creating that snapshot, it queries the server to determine which VSS writers have been installed. (It needs this list so it can later instruct each writer to quiesce its associated application). Then, the VSS requestor instructs each VSS writer to accomplish whichever task is needed for data quiescence. After each VSS writer reports that it has completed pre-backup tasks, the VSS requestor instructs the VSS provider to create a snapshot. The provider tells the requestor where to go to locate the data it needs and the backup begins. When the VM backup is complete, the VSS requestor announces that it has completed its activities. This announcement instructs each VSS writer to perform any post-backup tasks necessary so the computer and its applications can return to regular operation.
VSS writer - Each VSS-aware application installs its own VSS writer to a computer during the initial installation.
VSS requestor - Any application that needs to quiesce data for capture can play the role of VSS requestor.
VSS provider - The provider creates and manage the shadow copies of data on the system.
VMware's VADP (vStorage APIs for Data Protection) is technically superior to Microsoft's Hyper-V VSS(Volume Copy Shadow Service) because VADP supports Changed Block Tracking (CBT). On many file systems, CBT identifies the disk sectors altered between two change set IDs. On VMFS partitions, CBT can also identify all the disk sectors that are in use.
Virtual disk block changes are tracked from outside virtual machines, in the virtualization layer. When software performs a backup, it can request transmission of only the blocks that changed since the last backup, or the blocks in use. The CBT feature can be accessed by third-party applications as part of the vSphere APIs for Data Protection (VADP). Applications call VADP to request that the VMkernel return blocks of data that have changed on a virtual disk since the last backup snapshot.
VADP enables centralized, off-host LAN free backup of vSphere virtual machines, reduces ESX host resources to do backup processing, and enables flexible backup windows. A backup product using VADP can backup vSphere virtual machines from a central backup server or virtual machine without requiring backup agents or requiring backup processing to be done inside each guest virtual machine on the ESX host. This offloads backup processing from ESX hosts and reduces costs by allowing each ESX host to run more virtual machines.
VADP leverages the snapshot capabilities of VMware vStorage VMFS to enable backup across SAN without requiring downtime for virtual machines. As a result, backups can be performed non-disruptively at any time of the day without requiring extended backup windows and the downtime to applications and users associated with backup windows.
VSS, which operates at the block level of the file system, provides a backup infrastructure for Microsoft operating systems. The VSS requestor announces that it needs to create a server snapshot. Prior to creating that snapshot, it queries the server to determine which VSS writers have been installed. (It needs this list so it can later instruct each writer to quiesce its associated application). Then, the VSS requestor instructs each VSS writer to accomplish whichever task is needed for data quiescence. After each VSS writer reports that it has completed pre-backup tasks, the VSS requestor instructs the VSS provider to create a snapshot. The provider tells the requestor where to go to locate the data it needs and the backup begins. When the VM backup is complete, the VSS requestor announces that it has completed its activities. This announcement instructs each VSS writer to perform any post-backup tasks necessary so the computer and its applications can return to regular operation.
VSS writer - Each VSS-aware application installs its own VSS writer to a computer during the initial installation.
VSS requestor - Any application that needs to quiesce data for capture can play the role of VSS requestor.
VSS provider - The provider creates and manage the shadow copies of data on the system.
Subscribe to:
Posts (Atom)