Wednesday, August 22, 2012

the user name or password you entered isn't correct. try entering it again. owa


Bb691354.warning(en-us,EXCHG.141).gifWarning:
The following hotfixes only apply to Windows Server 2008 R2 RTM. If you’re installing Exchange on Windows Server 2008 R2 SP1, you don’t need to apply these hotfixes.
The following hotfixes are required for the Client Access server for Windows Server 2008 R2 RTM:
The following hotfix is required for Hub Transport and Mailbox servers for Windows Server 2008 R2:
The following hotfix is strongly recommended for Mailbox servers running Windows Server 2008 R2 that are members of a database availability group (DAG):
Install the update described in Knowledge Base article 2550886, A transient communication failure causes a Windows Server 2008 R2 failover cluster to stop working. Without this update, the underlying cluster for a DAG could experience a race condition that causes a loss of quorum in the cluster and a loss of functionality in the DAG.

  1. On servers that will host the Hub Transport or Mailbox server role, install the Microsoft Filter Pack. For Exchange 2010 RTM, see 2007 Office System Converter: Microsoft Filter Pack. For Exchange 2010 SP1, see Microsoft Office 2010 Filter Packs. For more information about registering the Filter Pack, see Register Filter Pack IFilters with Exchange 2010.
    Bb691354.note(en-us,EXCHG.141).gifNote:
    On Exchange 2010 RTM, you can meet the prerequisite by installing 2007 Office System Converter: Microsoft Filter Pack. However, we recommend that you upgrade to the Microsoft Office 2010 Filter Packs.
  2. On the Start menu, navigate to All Programs > Accessories > Windows PowerShell. Open an elevated Windows PowerShell console, and run the following command.
    Import-Module ServerManager
    
  3. Use the Add-WindowsFeature cmdlet to install the necessary operating system components:
    • This example is for a server that will have the typical installation of the Client Access, Hub Transport, and Mailbox server roles.
      Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,Web-Asp-Net,Web-Client-Auth,Web-Dir-Browsing,Web-Http-Errors,Web-Http-Logging,Web-Http-Redirect,Web-Http-Tracing,Web-ISAPI-Filter,Web-Request-Monitor,Web-Static-Content,Web-WMI,RPC-Over-HTTP-Proxy -Restart
      
    • This example is for a server that will host the Client Access, Hub Transport, Mailbox, and Unified Messaging server roles.
      Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,Web-Asp-Net,Web-Client-Auth,Web-Dir-Browsing,Web-Http-Errors,Web-Http-Logging,Web-Http-Redirect,Web-Http-Tracing,Web-ISAPI-Filter,Web-Request-Monitor,Web-Static-Content,Web-WMI,RPC-Over-HTTP-Proxy,Desktop-Experience -Restart
      
    • This example is for a server that will host the Client Access and Hub Transport server roles.
      Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,Web-Asp-Net,Web-Client-Auth,Web-Dir-Browsing,Web-Http-Errors,Web-Http-Logging,Web-Http-Redirect,Web-Http-Tracing,Web-ISAPI-Filter,Web-Request-Monitor,Web-Static-Content,Web-WMI,RPC-Over-HTTP-Proxy -Restart
      
    • This example is for a server that will host the Hub Transport and Mailbox server roles.
      Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server -Restart
      
    • This example is for a server that will host the Client Access and Mailbox server roles.
      Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,Web-Asp-Net,Web-Client-Auth,Web-Dir-Browsing,Web-Http-Errors,Web-Http-Logging,Web-Http-Redirect,Web-Http-Tracing,Web-ISAPI-Filter,Web-Request-Monitor,Web-Static-Content,Web-WMI,RPC-Over-HTTP-Proxy -Restart
      
    • This example is for a server that will host only the Client Access server role.
      Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,Web-Asp-Net,Web-Client-Auth,Web-Dir-Browsing,Web-Http-Errors,Web-Http-Logging,Web-Http-Redirect,Web-Http-Tracing,Web-ISAPI-Filter,Web-Request-Monitor,Web-Static-Content,Web-WMI,RPC-Over-HTTP-Proxy -Restart
      
    • This example is for a server that will host the Hub Transport or the Mailbox server role.
      Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server -Restart
      
    • This example is for a server that will host only the Unified Messaging server role.
      Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Desktop-Experience -Restart
      
    • This example is for a server that will host the Edge Transport server role.
      Add-WindowsFeature NET-Framework,RSAT-ADDS,ADLDS -Restart 
       
      http://technet.microsoft.com/en-us/library/bb691354.aspx
       

Thursday, August 16, 2012

Could not load all ISAPI filters for site/service. Therefore startup aborted.

ASP.NET 2.0, 32-bit version

To run the 32-bit version of ASP.NET 2.0, follow these steps:
  1. Click Start, click Run, type cmd, and then click OK.
  2. Type the following command to enable the 32-bit mode:
    cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 1
  3. Type the following command to install the version of ASP.NET 2.0 (32-bit) and to install the script maps at the IIS root and under:
    %SYSTEMROOT%\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -i
  4. Make sure that the status of ASP.NET version 2.0.50727 (32-bit) is set to Allowed in the Web service extension list in Internet Information Services Manager.

ASP.NET 2.0, 64-bit version

To run the 64-bit version of ASP.NET 2.0, follow these steps:
  1. Click Start, click Run, type cmd, and then click OK.
  2. Type the following command to disable the 32-bit mode:
    cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 0
  3. Type the following command to install the version of ASP.NET 2.0 and to install the script maps at the IIS root and under:
    %SYSTEMROOT%\Microsoft.NET\Framework64\v2.0.50727\aspnet_regiis.exe -i
  4. Make sure that the status of ASP.NET version 2.0.50727 is set to Allowed in the Web service extension list in Internet Information Services Manager.
Note The build version of ASP.NET 2.0 may differ depending on what the currently released build version is. These steps are for build version 2.0.50727.

Monday, August 13, 2012

windows cannot communicate with the device or resource primary dns server

The reset command is available in the IP context of the NetShell utility. Follow these steps to use the reset command to reset TCP/IP manually:
  1. To open a command prompt, click Start and then type CMD in the Search programs and files.
  2. Right-click CMD.exe icon in Programs and choose Run as administrator.
  3. When the User Account Control box pop up, click Yes.
  4. At the command prompt, copy and paste (or type) the following command and then press ENTER:
    netsh int ip reset c:\resetlog.txt
    Note If you do not want to specify a directory path for the log file, use the following command:
    netsh int ip reset resetlog.txt
     
    http://support.microsoft.com/kb/299357

Monday, August 6, 2012

How does AD AUTHENTICATION works

A question that comes up frequently involving federated customers is how does an organization need to configure its firewalls to allow users in a trusted, but not fully trusted, domain to access their resources.  Consider the following scenario:
[WEB RESOURCE]---|---FIREWALL---WAN---FIREWALL---|---[USER 2]
[DOMAIN CTRL A]--|                               |---[DOMAIN CTRL B]

User 2 wants to access a web resource in Domain A.  The two domains (A and B) are part of the same forest, but share a common root domain, through which replication occurs.  The domain controllers and other resources are not permitted for direct contact (because the firewalls are owned by someone else in the federation that doesn't care about making anything functional, only secure).  Under these circumstances, what exactly happens when User 2 attempts to connect and authenticate to the Web Resource?
  1. User 2 from Domain B logs onto Domain B workstation.
  2. Domain B workstation contacts Domain B KDC to get user authenticated.
  3. Domain B KDC creates a Ticket Granting Ticket (TGT) for User 2 on Domain B. Included in the TGT is PAC (Privilege Attribute Certificate) data, which is the list of the SIDs of the global, domain local and universal groups that user is a member of.

    NOTE: A GC (for any domain) would need to be contacted for the universal group enumeration.
  4. User 2's workstation receives TGT, extracts PAC data and puts the listed SIDs into an access token that is locally created. It also adds the SIDs of any machine local groups of which the user or the user’s groups are members. That access token is used on that machine only (tokens don’t traverse the wire).
  5. Every time User 2 accesses a member server in Domain B for the first time, User 2’s workstation uses the TGT to get a session ticket for the member server from the Domain B KDC. The KDC generates the session ticket and embeds the PAC data from the TGT that the user presented to the KDC (which keeps the KDC from having to authenticate over and over, but also means that the user has to log off and log back on to get a refreshed PAC from a KDC). The member server receives the session ticket and uses the PAC data in the same way that the workstation did, generating the access token locally and checking its local SAM for any additional SIDs to add to the token.
  6. When User 2 wants to access the Web Server resource in Domain A, User 2’s workstation goes to Domain B’s KDC to get a TGT for Domain A (this is what the trust relationship facilitates; KDCs on each end of the trust exchange long-term keys so that they can issue TGTs for each other.).
  7. User 2’s workstation presents the Domain A TGT to a Domain A KDC and requests a session ticket for the Domain A resource server (the web server in this case). Domain A's KDC works the same way as Domain B’s KDC did when it comes to constructing the session ticket for the member server, including just dumping the PAC data into the session ticket. The only difference is that the Domain B KDC actually constructed the Domain A TGT.
  8. The Domain A member server behaves just like a Domain B member server would and the Domain B workstation did.
Now, here's where the firewalls come in: if User 2’s workstation can’t contact a Domain A KDC, then Kerberos authentication will fail and it falls back to NTLM, and then we start dealing with pass-through authentication, which is going to require direct connectivity between the DCs for the different domains.  But, the web server doesn’t need to be able to access the source KDC (Domain B). Rather, User 2 needs to be able to access the Domain A KDC, which it probably can’t do if this federation is blocking this at the firewall. 
The problem can be somewhat compounded by the fact that the Domain Controller in Domain A won't necessarily be chosen on a consistent basis, so the hosting agency in the federation would need to allow access to potentially any DC in Domain A.  In other words, firewalls would need to be opened (gasp!). 
Actually, Microsoft has recognized this scenario with the R2 release of Windows Server 2003 and provided what is called Active Directory Federation Services, which do allow more control over which domain controllers are used for cross agency authentication.  The problem, however, is that ADFS is designed for a mulitple forest scenario, not multiple trusted domains in the same forest.

 http://blogs.msdn.com/b/anthonw/archive/2006/08/02/686041.aspx