Change Table and SP owner

DECLARE @old sysname, @new sysname, @sql varchar(1000)

SELECT
@old = 'oldOwner_CHANGE_THIS' ,
@new = 'dbo' ,
@sql = ' IF EXISTS (SELECT NULL FROM INFORMATION_SCHEMA.TABLES
WHERE
QUOTENAME(TABLE_SCHEMA)+''.''+QUOTENAME(TABLE_NAME) = ''?''
AND TABLE_SCHEMA = ''' + @old + ''' )
EXECUTE sp_changeobjectowner ''?'', ''' + @new + ''''

EXECUTE sp_MSforeachtable @sql

-------------------------------
The same can be done to stored procedures. This example works differently though. It doesn't actually make the change. Save the results in text and then paste the result back into Query Analyzer and run it.
-------------------------------

DECLARE @oldOwner sysname, @newOwner sysname
SELECT
@oldOwner = 'oldOwner_CHANGE_THIS' ,
@newOwner = 'dbo'
SELECT
'EXECUTE sp_changeobjectowner '''+QUOTENAME(a.SPECIFIC_SCHEMA)+'.'+QUOTENAME(a.ROUTINE_NAME)+''','''+@newOwner+''''
from INFORMATION_SCHEMA.ROUTINES a
where a.ROUTINE_TYPE = 'PROCEDURE' AND
a.SPECIFIC_SCHEMA = @oldOwner AND
OBJECTPROPERTY(OBJECT_ID(QUOTENAME (a.SPECIFIC_SCHEMA)+'.'+QUOTENAME(a.ROUTINE_NAME)), 'IsMSShipped') = 0

PPTP vs. L2TP

PPTP use two port

TCP/1723 to allow the PPTP control traffic, such as LCP, CHAP and most PPP option.
then use IP protocol 47 (Generic Routing Encapsulation) to move data. PPTP without MPPE is not secure. Actually MPPE is used in GRE to encrypt the data.

L2TP

From the Figure 3.0, actually there is not encrypt on L2TP. So when it use UDP as packet transport, it can be used over IPSec.

PPTP and L2Tp are layer 2 tunnel. GRE and IPSec are actually layer 3 tunneling.

Q. Do I need L2TP if I already have IPSec?
A. L2TP is a standard for Layer 2 tunneling. IPSec is a standard for encryption and security. They are independent, yet complementary standard efforts, and Cisco will provide the combination to take advantage of the strengths in both technologies. Strengths in L2TP include per-user authentication, dynamic address allocation from an address pool or by using DHCP server, and RADIUS and AAA support. Some of the strengths in IPSec are secure encryption and data confidentiality.

L2TP/IPSec or L2TP over IPSec

L2TP encapsulates original packets inside a PPP frame (performing compression when possible) and inside a User Datagram Protocol (UDP)-type packet assigned to port 1701. Because the UDP packet format is an IP packet, L2TP automatically uses IPSec to secure the tunnel, in accord with the security settings in the user configuration of the L2TP tunnel. The IPSec Internet Key Exchange (IKE) protocol negotiates security for the L2TP tunnel; certificate-based authentication is the default. This authentication process uses computer certificates, not user certificates, to verify that the source and destination computers both trust each other. If IPSec transport security is successfully established, L2TP negotiates the tunnel (including compression and user authentication options) and performs access control that is based on the user identity.

The L2TP/IPSec packet structure looks like the following example. The PPP Payload contains the original IP datagram, and the italicized text represents what is encrypted with IPSec.
IP headerIPSec ESP headerUDP headerL2TP headerPPP headerPPP PayloadIPSec ESP trailerIPSec Auth trailer

Microsoft Point-to-Point Encryption Protocol (MPPE), which can be used to secure the PPP payload when the Extensible Authentication Protocol Transport Layer Security (EAP-TLS) or Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP) is used, is negotiated by Windows when the L2TP peer (client or server) requests it.

MPPE uses the Rivest-Shamir-Adleman (RSA) RC4 stream encryption and either 40-bit, 56-bit, or 128-bit secret keys. MPPE keys are generated from the MS-CHAP and EAP-TLS user-authentication process. The remote access server can be configured to require data encryption. If the remote access client cannot perform the required encryption, the connection attempt is rejected and the following error message (#742) appears:
The remote computer does not support the required data encryption type.

IPSEC is negotiated before PPP starts; MPPE is negotiated after PPP starts. PPP runs over L2TP using IPSec. During the PPP authentication phase, a user name is sent to the Remote Access Server (RAS) component of the virtual private network (VPN) server by using the configured authentication protocol (MS-CHAP, for example). The RAS server then matches the user name and other call properties to a Remote Access Policy. Each policy has a profile, and RAS compares the conditions of the incoming call with the profile to determine whether to accept the connection request.

(Note: Basic L2TP/IPSec troubleshooting in windows XP )

Remotely enable Remote Desktop

On windows 2003 server,

WMIC /NODE:"ClientPCname" /USER:"DomainName\Administrator"
/PASSWORD:"Password" RDTOGGLE WHERE ServerName="ClientPCName"
CALL SetAllowTSConnections 1


You don't need to reboot the PC.

CBWFQ class-default queue

So, all queuing tools(PQ, CQ) support FIFO logic inside a single queue. But CBWFQ can use either FIFO or WFQ inside the class-default queue.

Note: 7500 router support FIFO or WFQ inside each and every CBWFQ queue..


When WRED enabled directly on physical interface, IOS support FIFO queueing only.

Only CBWFQ and LLQ can use WRED..

Flow-based WRED and WRED

FRED overcomes the problem of TCP starvation. When nonadaptive flows (UDP) compete with adaptive flows (TCP), WRED discards packetsfrom all the flows. However, only the TCP flows adapt, sending less traffic into the network, butUDP flows do not slow down. Queues can become filled with packets from large-volume UDPflows, causing the TCP flows to get progressively less queue space. This phenomenon is calledTCP starvation.

Firstly, FRED classifies eachflow into one of three FRED flow types:
1. Robust flows, which on average have a uniform data rate and slow down in response to congestion (TCP)
2. Fragile flows, which does not adapt to lost packets byslowing down, but the number of packetssent is not excessive (UDP)
3. Nonadaptive flows, which does not adapt to lost packets byslowing down, and the number ofpackets sent is excessive (UDP)

For UDP flows, FRED simply decides which flows are taking toomuch of the queue, classifies these flows as nonadaptive, and discards packets in those flowsmore aggressively. For other UDP flows that FRED believes are not sending too many packets(fragile flows) FRED discards their packets less frequently.

The key to understanding how FRED works is to understand how FRED determines whether aparticular UDP flow is fragile or nonadaptive. A couple of simple examples make the logicmuch more obvious. First, suppose FRED is enabled on a router’s S0/0 interface, and the interfaceFIFO output queue has 40 queue entries maximum. At a particular point in time, 10 flowsexist, called Flow 1, Flow 2, and so on. (Keep in mind that FRED only supports FIFO Queuing.)With a maximum queue depth of 40, and 10 flows, you can think of each flow’s fair share of thequeue space to be 40/10, or 4, in this case. FRED multiplies this fair share by a scaling factor,which defaults to 4. The scaling factor is used so that each flow has some capability to burst.This final number, 16 in this case, is the dividing line between fragile flows and nonadaptiveflows.

Suppose, for instance, that Flow 1 and Flow 2 both use UDP. Flow 1 has 3 packets in the FIFOoutput queue, and Flow 2 has 20 packets in the queue. At first glance, it seems that Flow 2should be considered a nonadaptive flow, because it has many packets in the queue. The calculatedvalue of 4 * 40/10 (scaling factor * maximum queue length/number of flows), or 16, isgreater than the number of packets in the queue that are part of Flow 1 (3 packets in the queue).

Therefore, FRED considers Flow 1 to be a fragile flow. Similarly, the calculated value of 16 issmaller than the number of packets in the queue that are part of Flow 2 (20 packets in thequeue), so FRED considers Flow 2 to be nonadaptive.

The first example hides one subtlety in how FRED decides which UDP flows are fragile, andwhich are nonadaptive. Consider the same example, but suppose now that only five flows exist.The formula works out to be 4 * 40/5 = 32. (Notice that the only part of the formula that changesover time is the number of flows; the scaling factor remains static, as does the maximum queuelength.) As the number of flows decreases, the threshold that determines whether a flow isnonadaptive increases. If Flow 2 still has 20 packets in the queue, Flow 2 would now beconsidered to be a fragile flow, with packets discarded less aggressively.

After FRED decides which flows are robust, fragile, and nonadaptive, FRED can apply WREDlikelogic to decide whether to discard any packets at all, and if so, what percentage of thepackets. Frankly, the published details on how FRED determines the flows are sketchy at best.For you QoS exam takers, the following details about how FRED discards packets for the threetypes of flows is unlikely to be covered, because the coverage in the corresponding courses isalso sketchy, or not even mentioned.

For robust and fragile flows, FRED acts just like WRED in terms of packet discard. FRED stilluses the per-precedence or per-DSCP minimum threshold, maximum threshold, and MPD todetermine when to discard packets, and how many. You can override the default values for eachprecedence or DSCP value through configuration, just like with WRED.

For nonadaptive flows, FRED lowers the maximum threshold. By doing so, FRED increases thepacket discard rate more quickly. More importantly, lowering the maximum threshold for packetsin the flow causes FRED to discard all packets for these nonadaptive flows more quicklythan for fragile and robust flows, essentially preventing these flows from consuming the entirequeue.

To get a full sense of what happens to nonadaptive flows, consider the following example. Fornonadaptive flows, FRED reduces the maximum threshold used for the flow by half of thedifference between the maximum and minimum thresholds. FRED and WRED use defaults forprecedence 0 as follows: minimum threshold 20, maximum threshold 40, drop percentage 10percent (MPD=10). FRED reduces the maximum threshold for a precedence 0 nonadaptiveflow to 30, because the difference between the maximum and minimum is 20, and half of thatis 10. By reducing the maximum threshold by half of the difference between the minimum andmaximum, FRED increases the packet discard rate more quickly as the average queue depthnears 30. Most importantly, FRED discards all packets for these nonadaptive precedence 0flows when the average queue depth reaches 30, preventing these flows from taking over theentire queue.

The two ends of an ATM physical link can be configured with different service classes

The two ends of an ATM physical link can be configured with different service classes. The service class type is not carried anywhere in the cell header. However, if you choose to do so, keep in mind the above differences in how the VC traffic is handled.

Reference:
Do Both Router Ends of an ATM PVC Need to Use the Same Traffic Shaping Values(http://www.cisco.com/warp/public/121/asymmetric_alpvc.html)

Site-to-Site VPN Benefits and Applications

Reduce WAN Costs, Increase WAN Flexibility
Using Internet transport, VPNs cut recurring WAN costs by 50 percent or more compared with traditional WAN technologies such as Frame Relay. And unlike Frame Relay, VPNs can be easily and quickly extended to new locations and extranet business partners.

Deliver New, Revenue-Enhancing Applications via VPNs
VPNs enable secure use of cost-effective, high-speed links such as DSL to deliver revenue-generating applications such as in-store online catalogs and ordering and efficiency tools such as online training.

Increase Data and Network Security
Traditional WANs using Frame Relay, leased lines, or ATM provide traffic segregation, not transport security. VPNs encrypt and authenticate traffic traversing the WAN to deliver true network security in an insecure, networked world.

Frame Relay or VPN

In addition to offering cost savings over Frame Relay, Cisco VPN solutions can meet or exceed Frame Relay performance measures.

Increased network security-
1.Frame Relay relies on traffic separation for data transport security. Although this method helps ensure that no one will accidentally gain access to your traffic, it does not prevent someone from illegally attempting to access your traffic. Because Frame Relay data is sent in cleartext, if someone does gain access to your data, they can read every word of it.
2. VPNs based on Cisco technology, however, offer 3DES and AES encryption methods, so your data is secure whether or not someone attempts to intercept traffic. Cisco MPLS VPN solutions offer the same type of logical traffic separation as Frame Relay. However, MPLS traffic can be encrypted by setting up IPSec tunnels through the MPLS network.

The net effect: Cisco VPNs are never less secure than Frame Relay, and in most cases are demonstrably more secure.