Understanding Exchange CAL

License Types

Exchange Server 2010 on-premise is licensed in the Server / Client Access License (CAL) model in exactly the same way that Exchange Server 2007 was licensed. There are three types of licenses:

1.  Server Licenses

A license must be assigned for each instance of the server software that is being run. The Exchange Server license is sold in two server editions:

·         Standard Edition: designed for the mailbox needs of small to medium organizations. Also appropriate for non-mailbox roles in a larger Exchange deployment.

·         Enterprise Edition: designed for larger organizations that may require a greater number of mailbox databases.

2.  Client Access Licenses (CALs)

Exchange requires a CAL for each user or device that accesses the server software.  There are two types of CALs for Exchange:

·         Standard CAL: designed to help users be more productive from virtually any platform, browser, or mobile device, with new features in Exchange Server 2010 that help manage communications overload and lower helpdesk costs.

·         Enterprise CAL: designed to allow organizations to reduce the costs and complexity of meeting compliance requirements with new integrated archiving functionality and information protection capabilities, while also helping you cut costs by replacing legacy voice mail systems with Unified Messaging.

The Enterprise CAL is sold as an add-on to the Standard CAL. To enable Standard CAL features for a user, the user must be licensed with just the Standard CAL. To enable Enterprise CAL features, the user must be licensed with one Standard CAL plus one Enterprise CAL. 

Note: Both CALs work with either Server Edition.

3.  External Connector Licenses

An External Connector permits an unlimited number of clients to access an Exchange Server in scenarios where the number of CALs is uncertain.

·         Access via the External Connector is limited to non-employees such as partners, suppliers, customers, and retirees.

·         The number of External Connector licenses required corresponds to the number of servers in the organization’s Exchange environment.

 

Exchange 2010 Feature Details

Exchange 2010 Server Licenses:
Existing features have been significantly enhanced and new features have been added to both of the Exchange Server editions. The following table provides a feature breakdown for each server edition of Exchange Server 2010:

Feature	Standard Server Edition	Enterprise Server Edition
Mailbox Databases	1-5 databases	6-100 databases
Roles Based Access & Control	Yes	Yes
Transport Resiliency	Yes	Yes
Remote PowerShell	Yes	Yes
Online Move Mailbox	Yes	Yes
Web-based administration	Yes	Yes
Mailbox Resiliency	Yes	Yes

Comparison to Earlier Versions
See the table below for detailed information about licensing differences from Exchange Server 2003 and Exchange Server 2007.

Feature	Exchange Server 2003 Standard Server	Exchange Server 2003 Enterprise Server	Exchange Server 2007 Standard Server	Exchange Server 2007 Enterprise Server	Exchange Server 2010 Standard Server	Exchange Server 2010 Enterprise Server
Mailbox Databases	1-2	3-20	1-5	6-50	1-5	6-100
Database Storage Limit	75GB	None	16TB	16TB	16TB	16TB
Single Copy Cluster	No	Yes	No	Yes	No	No
Local Continuous Replication	No	No	Yes	Yes	No	No
Standby Continuous Replication	No	No	Yes	Yes	No	No
Cluster Continuous Replication	No	No	No	Yes	No	No
Mailbox Resiliency	No	No	No	No	Yes	Yes

These tables capture several changes in licensing Exchange Server 2010 compared with earlier versions. In addition to the new functions, the major changes are:

·         The supported number of mailbox databases has increased from 50 to 100 in the Enterprise Server.

·         Exchange Server 2003 had different storage limits for Standard Server compared with Enterprise Server. In Exchange  Server 2007 and Exchange  Server 2010, the storage limit is increased to 16 TB for both Standard and Enterprise Server editions.

·         Several high-availability options have been consolidated into just one option for Exchange Server 2010 (Mailbox Resiliency), which is now offered in both the Standard and Enterprise editions.  The capabilities of Local Continuous Replication, Standby Continuous Replication, and Cluster Continuous Replication are now unified into the Exchange 2010 Mailbox Resiliency capability. These capabilities enable a simplified approach to high availability and disaster recovery.

Prerequisites for Exchange 2010 Server

For each Exchange Server 2010 instance, you must also purchase a Windows Server 2008 license. The edition of Windows Server that is required depends on which features of Exchange Server 2010 you will be using. For Exchange 2010 servers that use Mailbox Resiliency features for high availability, either Windows Server 2008 Enterprise or Datacenter editions are required for its clustering features. For all other Exchange 2010 scenarios, Windows Server Standard is appropriate.

Therefore, these are the possible scenarios and necessary prerequisites:

Exchange Server Edition	Scenario	Windows Server Edition
Exchange Server 2010 Standard Edition	No Mailbox Resiliency	Standard Server
Exchange Server 2010 Enterprise Edition	No Mailbox Resiliency	Standard Server
Exchange Server 2010 Standard Edition	Mailbox Resiliency	Enterprise /Datacenter Server
Exchange Server 2010 Enterprise Edition	Mailbox Resiliency	Enterprise /Datacenter Server

Exchange 2010 Client Access Licenses (CALs)

As with the Server licenses, the Exchange Server 2010 CALs have also been significantly improved from the previous versions of Exchange. The following table provides a detailed feature breakdown for each CAL edition of Exchange Server 2010:

Feature	Standard CAL	Std. + Ent. CAL
E-mail, Calendar, Contacts, and Tasks	Yes	Yes
Outlook Web App (Internet Explorer, Firefox, and Safari support)	Yes	Yes
Exchange ActiveSync Mobile Access	Yes	Yes
Rich Outlook inbox experience, including enhanced Conversation View and Mail Tips	Yes	Yes
Role Based Administration Control capabilities	Yes	Yes
Integration of IM, SMS, and RSS	Yes	Yes
Federated Calendar Sharing	Yes	Yes
Exchange ActiveSync Mobile Management Policies	Standard	Standard and Advanced
Journaling	Per Database	All
Voicemail with Unified Messaging	No	Yes
Retention Policies	Default	Default and Custom
Integrated Archive	No	Yes
Multi-Mailbox Search and Legal Hold	No	Yes
Information Protection & Control (IPC):  journal decryption, transport protection rules, Outlook protection rules, IRM Search, and Legal Hold	No	Yes

Customers may buy the standard CAL standalone, but those who want to acquire the Enterprise features as listed above must purchase both the standard and the Enterprise CALs.

For volume licensing customers, the Enterprise CAL is also available with antivirus and anti-spam service subscriptions from Microsoft Forefront.

Feature	Standard CAL	Enterprise CAL with Services	Std. + Ent. CAL with Services
Forefront Security for Exchange Server		Yes	Yes
Forefront Online Security for Exchange		Yes	Yes

Comparison to Earlier Versions

The table below includes detailed information about differences in licensing Exchange Server 2010 compared with Exchange Server 2003 and Exchange Server 2007.

Feature	Exchange Server 2003 Exchange CAL	Exchange Server 2007 Standard CAL	Exchange Server 2007 Enterprise CAL	Exchange Server 2007 Std. + Ent. CAL	Exchange Server 2010 Standard CAL	Exchange Server 2010 Enterprise CAL	Exchange Server 2010 Std. + Ent. CAL
Outlook Client	Yes	No	No	No	No	No	No
Mailbox Manager	Yes	No	No	No	No	No	No
Managed Folders	No	Default	Custom	All	Default	Custom	All
Retention Policies	No	No	No	No	Default	Custom	All
Advanced Exchange ActiveSync Mobile Policies	No	No	Yes	Yes	No	Yes	Yes
Journaling	Per Database	Per Database	Per User/DL	All	Per Database	Per User/DL	All
Voicemail with Unified Messaging	No	No	Yes	Yes	No	Yes	Yes

Apart from new functions, there are several major changes for licensing Exchange 2010 compared to earlier versions:

·         The Exchange 2003 license was sold with just one CAL, while the Exchange 2007 and Exchange 2010 licenses are sold with both Standard and Enterprise CALs.

·         The Exchange 2003 CAL included rights to the Outlook client. In Exchange 2007 and Exchange 2010, the Outlook client license must be purchased separately.

·         Features for managing e-mail retention have evolved from Mailbox Manager in Exchange 2003 to Managed Folders in Exchange 2007 to Retention Policies in Exchange 2010.

·         Advanced Exchange ActiveSync mobile policies were introduced in the Exchange 2007 Enterprise CAL at SP1.

·         Unified Messaging, Managed Folders, and Per-user/Per-distribution list Journaling were introduced in the Exchange 2007 Enterprise CAL.

Prerequisites for Exchange 2010 Client Access Licenses (CALs):

For each Exchange Server 2010 CAL, there are two possible prerequisites for the underlying Microsoft technologies. First, a Windows Server 2008 CAL is required for each user or device in all scenarios. Second, a Windows 2008 Rights Management Server (RMS) CAL is required for each Exchange Server 2010 user or device that will be making use of the Information Rights Management (IRM) features.

Therefore, these are the possible scenarios and necessary prerequisites:

Exchange Server	Scenario	Windows Server CAL Required?	RMS CAL Required?
Exchange Server 2010 Standard CAL	Using IRM	Yes	Yes
Exchange Server 2010 Standard & Enterprise CAL	Not using IRM	Yes	No
Exchange Server 2010 Standard & Enterprise CAL	Using IRM	Yes	Yes

Active Directory Maximum Limits

This topic describes Active Director scalability and other limitations, as well as recommendations that apply when you are designing or implementing an Active Directory infrastructure. These limitations include the following:
• Maximum Number of Objects
• Maximum Number of Security Identifiers
• Group Memberships for Security Principals
• FQDN Length Limitations
• File Name Length Limitations
• Additional Name Length Limitations
• Maximum Number of GPOs Applied
• Trust Limitations
• Maximum Number of Accounts per LDAP Transaction
• Recommended Maximum Number of Users in a Group
• Recommended Maximum Number of Domains in a Forest
• Recommended Maximum Number of Domain Controllers in a Domain
• Recommended Maximum Kerberos Settings
Maximum Number of Objects
Each domain controller in an Active Directory forest can create a little bit less than 2.15 billion objects during its lifetime.
Each Active Directory domain controller has a unique identifier that is specific to the individual domain controller. These identifiers, which are called Distinguished Name Tags (DNTs), are not replicated or otherwise visible to other domain controllers. The range of values for DNTs is from 0 through 2,147,483,393 (231 minus 255). As objects are created on a domain controller, a unique value is used. A DNT is not reused when an object is deleted. Therefore, domain controllers are limited to creating approximately 2 billion objects (including objects that are created through replication). This limit applies to the aggregate of all objects from all partitions (domain NC, configuration, schema, and any application directory partitions) that are hosted on the domain controller.
Because new domain controllers start with low initial DNT values (typically, anywhere from 100 up to 2,000), it may be possible to work around the domain controller lifetime creation limit—assuming, of course, that the domain is currently maintaining less than 2 billion objects. For example, if the lifetime creation limit is reached because approximately 2 billion objects are created, but 500 million objects are removed from the domain (for example, deleted and then permanently removed from the database through the garbage collection process), installing a new domain controller and allowing it to replicate the remaining objects from the existing domain controllers is a potential workaround. However, it is important that the new domain controller receives the objects through replication and that such domain controllers not be promoted with the Install from Media (IFM) option. Domain controllers that are installed with IFM inherit the DNT values from the domain controller that was used to create the IFM backup.
At the database level, the error that occurs when the DNT limit is reached is “Error: Add: Operations Error. <1> Server error: 000020EF: SvcErr: DSID-0208044C, problem 5012 (DIR_ERROR), data -1076.”
Maximum Number of Security Identifiers
There is a limit of approximately 1 billion security identifiers (SIDs) over the life of a domain. This limit is due to the size of the global relative identifier (RID) pool of 30 bits that makes each SID (that is assigned to user, group, and computer accounts) in a domain unique. The actual limit is 230 or 1,073,741,823 RIDs. Because RIDs are not reused—even if security principals are deleted—the maximum limit applies, even if there are less than 1 billion security principals in the domain.


RIDs are assigned in blocks of 500 by default from the domain controller that holds the RID operations master role in each domain. If a domain controller is demoted, the unused RIDs that were allocated to the domain controller are not returned to the global RID pool and are therefore no longer available for use in the domain.
When all the available RIDs are assigned for a domain, the Directory Service log in the Application and Service Logs of Event Viewer also displays Event ID 16644 from an event log source of the Security Accounts Manager (SAM) that reads “The maximum domain account identifier value has been reached. No further account-identifier pools can be allocated to domain controllers in this domain.” If you run Dcdiag when all the available RIDs are assigned for a domain, you see the error message “The DS has corrupt data: rIDAvailablePool value is not valid.”
A partial work-around to this limitation is to create an additional domain to hold accounts and then migrate accounts to the new domain. However, you must create a trust relationship to migrate accounts in advance of reaching the limit. Creating a trust requires the creation of a security principal, which is also known as a trust user account. For more information about this limit, see articles 316201 (http://go.microsoft.com/fwlink/?LinkID=115211) and 305475 (http://go.microsoft.com/fwlink/?LinkId=115212) in the Microsoft Knowledge Base.

The Active Directory database does not set limits on the number of objects in a container, such as organizational units (OUs). You might experience limits when you work with multiple thousands of objects. These limits are configured to help provide a certain level of application or service availability. For example, the Active Directory Users and Computers snap-in is configured by default to display a maximum of 2,000 objects per container. You can adjust this value by using the Filter Options settings on the View menu. There are also adjustable Lightweight Directory Access Protocol (LDAP) policies that are set by default to improve domain controller performance. These policies are described in article 315071 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=135481).

Group Memberships for Security Principals
Security principals (that is, user, group, and computer accounts) can be members of a maximum of approximately 1,015 groups. This limitation is due to the size limit for the access token that is created for each security principal. For more information, see article 328889 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=115213). For a detailed discussion of access token limitations, see Addressing Problems Due to Access Token Limitation (http://go.microsoft.com/fwlink/?LinkId=146571).
FQDN Length Limitations
Fully qualified domain names (FQDNs) in Active Directory cannot exceed 64 characters in total length, including hyphens and periods (.). For example, the following host name has 65 characters; therefore, it is not valid in an Active Directory domain:
server10.branch-15.southaz.westernregion.northamerica.contoso.com
This is an important limitation to keep in mind when you name domains. This limitation is due to the MAX_PATH length of 260 characters that the Win32 application programming interfaces (APIs) define, in combination with the way in which Group Policy objects (GPOs) are stored in the SYSVOL share. For more information, see article 245809 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=115219). For more information about naming limitations, see article 909264 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=106629).
File Name Length Limitations
The file system that Windows operating systems use limits the length of file names—including the path to the file name—to 260 characters. This limitation applies also to physical files that Active Directory components use, such as SYSVOL and database file paths. When you are determining where to place your SYSVOL and database files during Active Directory installation, avoid nested folder structures that might make the full file path to the SYSVOL folder longer than 260 characters. For more information, see article 245809 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=115219).
Additional Name Length Limitations
There are additional limitations regarding name lengths in Active Directory. The following limits are described in article 909264 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=106629):
• NetBIOS computer and domain names are limited to 15 characters.
• Domain Name System (DNS) host names are limited to 24 characters.
• OU names are limited to 64 characters.
Name Length Limits from the Schema
Default limits on attribute names for Active Directory objects that are imposed by the schema include the following. These items provide examples of schema-limited name attributes:
• Display names are limited to 256 characters. For more information, see Display-Name Attribute (http://go.microsoft.com/fwlink/?LinkId=153705).
• Common names are limited to 64 characters. For more information, see Common-Name Attribute (http://go.microsoft.com/fwlink/?LinkId=153706).
• The SAM-Account-Name attribute (also known as the pre–Windows 2000 user logon name) is limited to 256 characters in the schema. However, for the purpose of backward compatibility the limit is 20 characters. For more information, see SAM-Account-Name Attribute (http://go.microsoft.com/fwlink/?LinkId=153707).
Name Length Limitations for LDAP Simple Bind Operations
During binds to the directory, simple LDAP bind operations limit the distinguished name (also known as DN) of the user to 255 total characters. If you attempt a simple LDAP bind with more than 255 characters, you might experience authentication errors, such as the following:
Error <49>: ldap_simple_bind_s() failed: Invalid Credentials
Server error: 80090308: LdapErr: DSID-0C0903AA, comment: AcceptSecurityContext error, data 57, v1771
Error 0x80090308 The token supplied to the function is invalid
You can avoid this issue by ensuring that the applications, scripts, and utilities that attempt to bind to your directory use secure LDAP binds. You can also avoid this issue by reducing the depth of the OU structure or the length of the OU names. For example, the following distinguished name is 261 characters:
CN=BobKelly,OU=CorporateVicePresidents,OU=CorporateOfficers,OU=ViewOfPugetSoundOffices,OU=TopFloor,OU=Building1557,OU=CorporateCampus,OU=Redmond,OU=Washington,OU=NorthWestern,OU=UnitedStatesOfAmerica,OU=NorthAmerica,DC=BusinessGroup,DC=humongousinsurance,DC=com
If the OU named CorporateVicePresidents is shortened to CVP, the distinguished name for the user account BobKelly is only 242 characters.
Maximum Number of GPOs Applied
There is a limit of 999 Group Policy objects (GPOs) that you can apply to a user account or computer account. This does not mean that the total number of policy settings on the system is limited to 999. Rather, a single user or computer will not be able to process more than 999 GPOs. This limit exists for performance reasons.
Trust Limitations
Trust limitations arise from the number of trusted domain objects (TDOs), the length of trust paths, and the ability of clients to discover available trusts. Limitations that apply include the following:
• Kerberos clients can traverse a maximum of 10 trust links to locate a requested resource in another domain. If the trust path between the domains exceeds this limit, the attempt to access the domain fails.
• When a client searches out a trust path, the search is limited to the trusts that are established directly with a domain and the trusts that are transitive within a forest.
• Previous testing shows that the increased time to complete TDO-related operations, such as authentication across domains, deteriorates performance noticeably if the Active Directory implementation in an organization contains more than 2,400 TDOs.
For more information about trust limitations, see “Practical Limitations of Trusts” in How Domain and Forest Trusts Work (http://go.microsoft.com/fwlink/?LinkID=35356).
Maximum Number of Accounts per LDAP Transaction
When you write scripts or applications that perform LDAP transactions, the recommended limit is to perform no more than 5,000 operations per LDAP transaction. An LDAP transaction is a group of directory operations (such as add, delete, and modify) that are treated as one unit. If your script or application performs more than 5,000 operations in a single LDAP transaction, you are at risk of running into resource limits and an operational time-out. If that happens, all the operations (changes, additions, and modifications) in the transaction are rolled back, which means that you lose all those changes.
As an example, if you are using Active Directory Service Interfaces (ADSI) to write a script, the SetInfo method completes a transaction. For more information about ADSI Methods, see Active Directory Service Interfaces (http://go.microsoft.com/fwlink/?LinkID=4487).
As another example, when you use the System.DirectoryServices (S.DS) namespace in the Microsoft .Net Framework, the DirectoryEntry.CommitChanges method completes an LDAP transaction. For more information about the DirectoryEntry.CommitChanges method, see DirectoryEntry.CommitChanges () (http://go.microsoft.com/fwlink/?LinkId=115220).

Regardless of the method that you use for LDAP transactions, you should plan to send less than 5,000 directory operations in a single transaction. To learn more about the LDAP data structure that commits changes, see LDAPMod (http://go.microsoft.com/fwlink/?LinkId=115221).

Recommended Maximum Number of Users in a Group
For Windows 2000 Active Directory environments, the recommended maximum number of members in a group is 5,000. This recommendation is based on the number of concurrent atomic changes that can be committed in a single database transaction.
Starting with Windows Server 2003, the ability to replicate discrete changes to linked multivalued properties was introduced as a technology called Linked Value Replication (LVR). To enable LVR, you must increase the forest functional level to at least Windows Server 2003 interim. Increasing the forest functional level changes the way that group membership (and other linked multivalued attributes) is stored in the database and replicated between domain controllers. This allows the number of group memberships to exceed the former recommended limit of 5,000 for Windows 2000 or Windows Server 2003 at a forest functional level of Windows 2000.
So far, testing in this area has yet to reveal any new recommended limits to the number of members in a group or any other linked multivalued attribute. Production environments have been reported to exceed 4 million members, and Microsoft scalability testing reached 500 million members.
Important

Increasing the forest functional level to Windows Server 2003 interim or higher does not modify the way that existing group members are stored or replicated. To do that, you must remove the members that were added to the group before the forest functional level was increased to Windows Server 2003 and then add them back again to the appropriate groups. Any group members that you either add or remove after the forest functional level is increased will be LVR enabled, even if the group contains other members that are not LVR enabled.
For more information about linked attributes, see Linked Attributes (http://go.microsoft.com/fwlink/?LinkId=142909). For more information about the replication process, see How the Active Directory Replication Model Works (http://go.microsoft.com/fwlink/?LinkId=142908).

Recommended Maximum Number of Domains in a Forest
For Windows 2000 Server, the recommended maximum number of domains in a forest is 800. For Windows Server 2003, the recommended maximum number of domains when the forest functional level is set to Windows Server 2003 (also known as forest functional level 2) is 1,200. This restriction is a limitation of multivalued, nonlinked attributes in Windows Server 2003. For more information, see “Maximum Database Record Size” in How the Data Store Works (http://go.microsoft.com/fwlink/?LinkId=134791).
Recommended Maximum Number of Domain Controllers in a Domain
Because the File Replication Service (FRS) is used to replicate SYSVOL in a Windows Server 2003 domain, we recommend a limit of 1,200 domain controllers per domain to ensure reliable recovery of SYSVOL.
If any Active Directory domain in your network is expected to exceed 800 domain controllers and those domain controllers are hosting Active Directory–integrated Domain Name System (DNS) zones, review article 267855 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=115222).
For more information about FRS limitations, see the FRS Technical Reference (http://go.microsoft.com/fwlink/?LinkId=115302).
Recommended Maximum Kerberos Settings
The maximum recommended size for a Kerberos ticket is 65,535 bytes, which is configured through the MaxTokenSize REG_DWORD value in the registry (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Lsa\Kerberos\Parameters). Increasing this value from the default may cause errors, particularly when Web browsers or Web servers are used. For additional information about Kerberos tickets, including error conditions that can occur when Kerberos ticket size limits are set too low or too high, see Additional Resources for Troubleshooting Kerberos (http://go.microsoft.com/fwlink/?LinkId=134740).

Something you should know !

Hi ALL
Many ppl dont know that they cannot create "CON" folder in windows. (Type 1)

Some ppl dont know why they cant create it? (Type 2)

Very few know that they can still create it someway.. but donno why are they supposed to do exactly like that..(Type 3)

Now, After reading this tutorial, you will become one of the rest
__________________________________________________ _________________________

Type 1 :

Try out creating a folder named CON or LPT or COM1

Now, you have become Type 2 category.
__________________________________________________ _________________________

Type 2 :

Not only CON, we cannot create any of these
CON, PRN, AUX, CLOCK$, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9 and more

The reason is that con, prn, lpt1..lpt9, etc are underlying devices from the time dos was written. so if u r allowed to create such folders, there will be an ambiguity in where to write data when the data is supposed to go to the specified devices. In other words, if i want to print something, internally what windows does is -- it will write the data to the folder prn (virtually u can call it a folder, i mean prn, con, etc are virtual folders in device level). So if we are able to create con folder, windows will get confused where to write the data, to virtual con folder or real one.

So Now, Try this...

Open the Command prompt by Start -> Run and typing cmd
Code:
C:\> md \\.\c:\con
Now, Open My Computer and browse through the path where you created CON folder... Surprising.. ?? Yeah.. you have created it successfully

Now, try to delete the folder from My computer

OOPS!!! You cant delete it...

Now, try this in command prompt console
Code:
C:\> rd \\.\c:\con
Yeah!! You did it...
__________________________________________________ __________________________

Type 3 :

Well, let us now have a glance at how we were able to create it...

It is just because of the UNC Path ( Universal Naming Convention) - Wikipedia, the free encyclopedia. The Universal Naming Convention, or UNC, specifies a common syntax to describe the location of a network resource, such as a shared file, directory, or printer.Since, these conventions did n't exist under pure DOS, they are not backward compatible. The UNC syntax for Windows systems is as follows..

\\RemoteHost\sharedfolder\ resource

where RemoteHost is the computer name / IP address of the computer that you wish to connect through remotely for accessing shared folder. The rest is the path.

(Here \\remotehost\drive:\con doesn't make sense anyway, because without having a process on the remote host, there is no current 'console'). It would be a security hazard as well, having the serial and parallel ports accessible for everyone who is allowed to read or write in any single directory.

The " ." in the command \\.\c:\con suggest the local server. Now, you are pointing to your own computer. since, you have all privilages on every folder of ur computer, you can easily create it.
__________________________________________________ _____________________________

Type 4 :

Of course, Now, u r of type 4. What else i can say :

Restricting Active Directory replication traffic and client RPC traffic to a specific port

By default, Active Directory replication remote procedure calls (RPC) occur dynamically over an available port through the RPC Endpoint Mapper (RPCSS) by using port 135. This process is the same process as in Microsoft Exchange. As in Microsoft Exchange, an administrator can override this functionality and specify the port that all Active Directory RPC traffic passes through. This procedure locks the port down.

When you specify ports to use by using the registry entries that are mentioned in the below, both Active Directory server-side replication traffic and client RPC traffic are sent to these ports by the endpoint mapper. This configuration is possible because all RPC interfaces that are supported by Active Directory are running on all ports on which it is listening.

Note This article does not imply that replication can occur through a firewall. Additional ports must be opened to make replication work through a firewall. For example, additional ports must be opened for the Kerberos protocol.

When you connect to an RPC endpoint, the RPC runtime on the client contacts the RPC endpoint mapper (RPCSS) on the server at a well-known port (135) and obtains the port to connect to for the service supporting desired RPC interface. This assumes that the client does not know the complete binding. This is the case with all AD RPC services.

The service registers one or more endpoints when it starts, and has the choice of a dynamically assigned port or a specific port.

If you configure Active Directory and Netlogon to run at "port x" as in the following entry, this becomes the ports that are registered with the endpoint mapper in addition to the standard dynamic port.

Use Registry Editor to modify the following values on each domain controller where the restricted ports are to be used. Member servers are not considered to be logon servers. Therefore, static port assigment for NTDS and Netlogon has no effect on them.

Registry key 1
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Registry value: TCP/IP Port
Value type: REG_DWORD
Value data: (available port)
Registry key 2
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Registry value: DCTcpipPort
Value type: REG_DWORD
Value data: (available port)

Administrators should confirm that if any intermediate network devices or software is used to filter packets between domain controllers, that communication over the specified port is enabled. Both the replication and the netlogon should be set to use different ports.

Note When you use the DCTcpipPort registry entry, and you set it to the same port as the TCP/IP Port registry entry, you receive Netlogon error event 5809 under NTDS\Parameters. This indicates that the port configured is in use. In this case, you should remove the DCTcpipPort registry entry. You will receive the same event when you have a unique port, and you restart the Netlogon service on the domain controller. This is by design, and occurs because of the way the RPC runtime manages its server ports. The port for Netlogon is still being registered with the runtime, even when you stop the Netlogon service. The port will be used after the restart, and the event can be ignored.

If you are setting the Active Directory replication to a fixed port outside the range that is allowed for RPC ports to control access and logons through a firewall, the replication port and the dynamic RPC ports will have to be opened on the firewall to allow access and logons. This is because logon uses the Replication Port for user mapping.

You may want to set the Active Directory replication to a fixed port outside the range that is allowed for RPC ports. You may want to do this to control access and logons through a firewall. However, because of this, the replication and Netlogon port must be opened on the firewall. This is because the logon process uses the Replication Port for user mapping.

exchange monitoring tool..

Check this site for a cool tool for live monitoring of exchange servers..

http://www.bitrunes.com/

This tool is especially useful for Exchange administrators and developers. By using this tool, you can gather real-time data about the users in an Exchange environment and learn more about the inner workings of MAPI, OWA, POP3, IMAP4, NNTP and other protocols.

folder names that we cant create in windows machine...

Check how can we create these folders anywhere in a windows machine..

CON, PRN, AUX, CLOCK$, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9.

Logon Type Codes Revealed

The logon/logoff category of the Windows security log gives you the ability to monitor all attempts to access the local computer. In this article I’ll examine each logon type in greater detail and show you how some other fields in Logon/Logoff events can be helpful for understanding the nature of a given logon attempt.

Event IDs 528 and 540 signify a successful logon, event ID 538 a logoff and all the other events in this category identify different reasons for a logon failure. However, just knowing about a successful or failed logon attempt doesn’t fill in the whole picture. Because of all the services Windows offers, there are many different ways you can logon to a computer such as interactively at the computer’s local keyboard and screen, over the network through a drive mapping or through terminal services (aka remote desktop) or through IIS. Thankfully, logon/logoff events specify the Logon Type code which reveals the type of logon that prompted the event. 

Logon Type 2 – Interactive

This is what occurs to you first when you think of logons, that is, a logon at the console of a computer. You’ll see type 2 logons when a user attempts to log on at the local keyboard and screen whether with a domain account or a local account from the computer’s local SAM. To tell the difference between an attempt to logon with a local or domain account look for the domain or computer name preceding the user name in the event’s description. Don’t forget that logon’s through an KVM over IP component or a server’s proprietary “lights-out” remote KVM feature are still interactive logons from the standpoint of Windows and will be logged as such. 

Logon Type 3 – Network

Windows logs logon type 3 in most cases when you access a computer from elsewhere on the network. One of the most common sources of logon events with logon type 3 is connections to shared folders or printers. But other over-the-network logons are classed as logon type 3 as well such as most logons to IIS. (The exception is basic authentication which is explained in Logon Type 8 below.)

Logon Type 4 – Batch

When Windows executes a scheduled task, the Scheduled Task service first creates a new logon session for the task so that it can run under the authority of the user account specified when the task was created. When this logon attempt occurs, Windows logs it as logon type 4. Other job scheduling systems, depending on their design, may also generate logon events with logon type 4 when starting jobs. Logon type 4 events are usually just innocent scheduled tasks startups but a malicious user could try to subvert security by trying to guess the password of an account through scheduled tasks. Such attempts would generate a logon failure event where logon type is 4. But logon failures associated with scheduled tasks can also result from an administrator entering the wrong password for the account at the time of task creation or from the password of an account being changed without modifying the scheduled task to use the new password.

Logon Type 5 – Service

Similar to Scheduled Tasks, each service is configured to run as a specified user account. When a service starts, Windows first creates a logon session for the specified user account which results in a Logon/Logoff event with logon type 5. Failed logon events with logon type 5 usually indicate the password of an account has been changed without updating the service but there’s always the possibility of malicious users at work too. However this is less likely because creating a new service or editing an existing service by default requires membership in Administrators or Server Operators and such a user, if malicious, will likely already have enough authority to perpetrate his desired goal.

Logon Type 7 – Unlock

Hopefully the workstations on your network automatically start a password protected screen saver when a user leaves their computer so that unattended workstations are protected from malicious use. When a user returns to their workstation and unlocks the console, Windows treats this as a logon and logs the appropriate Logon/Logoff event but in this case the logon type will be 7 – identifying the event as a workstation unlock attempt. Failed logons with logon type 7 indicate either a user entering the wrong password or a malicious user trying to unlock the computer by guessing the password.

Logon Type 8 – NetworkCleartext

This logon type indicates a network logon like logon type 3 but where the password was sent over the network in the clear text. Windows server doesn’t allow connection to shared file or printers with clear text authentication. The only situation I’m aware of are logons from within an ASP script using the ADVAPI or when a user logs on to IIS using IIS’s basic authentication mode. In both cases the logon process in the event’s description will list advapi. Basic authentication is only dangerous if it isn’t wrapped inside an SSL session (i.e. https). As far as logons generated by an ASP, script remember that embedding passwords in source code is a bad practice for maintenance purposes as well as the risk that someone malicious will view the source code and thereby gain the password.

Logon Type 9 – NewCredentials

If you use the RunAs command to start a program under a different user account and specify the /netonly switch, Windows records a logon/logoff event with logon type 9. When you start a program with RunAs using /netonly, the program executes on your local computer as the user you are currently logged on as but for any connections to other computers on the network, Windows connects you to those computers using the account specified on the RunAs command. Without /netonly Windows runs the program on the local computer and on the network as the specified user and records the logon event with logon type 2.

Logon Type 10 – RemoteInteractive

When you access a computer through Terminal Services, Remote Desktop or Remote Assistance windows logs the logon attempt with logon type 10 which makes it easy to distinguish true console logons from a remote desktop session. Note however that prior to XP, Windows 2000 doesn’t use logon type 10 and terminal services logons are reported as logon type 2.

Logon Type 11 – CachedInteractive

Windows supports a feature called Cached Logons which facilitate mobile users. When you are not connected to the your organization’s network and attempt to logon to your laptop with a domain account there’s no domain controller available to the laptop with which to verify your identity. To solve this problem, Windows caches a hash of the credentials of the last 10 interactive domain logons. Later when no domain controller is available, Windows uses these hashes to verify your identity when you attempt to logon with a domain account.

Conclusion

I hope this discussion of logon types and their meanings helps you as you keep watch on your Windows network and try to piece together the different ways users are accessing your computers. Paying attention to logon type is important because different logon types can affect how you interpret logon events from a security perspective. For instance a failed network logon on a server might now be surprising since users must access servers over the network all the time. But a failed network logon attempt in a workstation security log is different. Why is anyone trying to access someone else’s workstation from over the network? As you can see, it pays to understand the security log

aken from ntsecapi.h in the security subdirectory on the Win32 SDK CD. Used by a logon process to indicate what type of logon is being requested.

typedef enum _SECURITY_LOGON_TYPE

{

Interactive = 2,   // Interactively logged on (locally or remotely)

Network = 3,       // Accessing system via network

Batch = 4,         // Started via a batch queue

Service = 5,       // Service started by service controller

Proxy = 6,         // Proxy logon

Unlock = 7         // Unlock workstation

}

Logon Events (interactive):

A successful logon event generates Event ID 528, Logon Type 2. A logoff event generates Event ID 538, Logon Type 2.

Connection Events (network):

A successful Net Use or File Manager connection or a successful Net View generates Event ID 528, Logon Type 3.

Connection events are sessions at the server level and are generated only by the initial connection from a particular user. Later Net Views or Net Uses from the same user to the same computer do not generate logged events unless the user has disconnected (or has been autodisconnected) from all shares.