How to enable detailed errors for remote client - IIS7

By default IIS 7.0 (Internet Information Service), shows the detailed error when you're browsing locally, but if you are remoting as a normal web client to the webserver, you won't be able to see the error, except the default '500 - Internal server error'.
Here is the guide to enable the detailed error, within IIS 7.0
First of all, you need access to IIS controlpanel, and the Webconfig from the specific website, you want's to see the detailed error from. In the Webconfig, it's very important that you have specified the CustomError mode to Off, otherwise your local configs would overwrite the server default settings. Please check you got the same setup as the example below.
<system.web>
<customErrors mode="Off" />
</system.web>
If you still receive the default error, you have to change the server custom error module settings. You can do this from the IIS7 Admin tool by running the server manager, or writing inetmgr.exe from the Run command.

1. Select your website, at the left menu
2. Click on the "Error Pages" button
3. Click on the action "Edit Feature Settings" at the right menu
4. Pick the "Detailed errors" option
5. Confirm the change by clicking "OK"

You should now be able to see the detailed error from the IIS7 webserver, from your remote location. Check the picture below, to verify you got the same settings.

http://dnohr.dk

Windows - Certificate Auto Enrollment Fails

KB ID 0000921 Dtd 01/02/14

Problem

I was trying to get Windows 7 to auto enroll with a CA on Windows 2008 R2, after a couple of reboots the certificates were simply not appearing on the test client I was working on.

Solution

1. Test to make sure the client can see the CA, and is able to communicate with it, issue the following command;

certutil -pulse

As you can see above, the first time I ran the command I got the following error;
CertUtil: -pulse command FAILED: 0x80070005 (WIN32: 5)
CertUtil: Access is denied.
I then ran the command window 'as administrator' and it completed, this was the first inkling I had, that permissions were probably not right.
2. Run mmc on an affected machine, and add in the certificates (local computer*) snap-in. right click the 'personal container' > attempt to get the certificate you have published manually.
*Or local user if you are auto enrolling user certificates.

At that point I got this error;
Active Directory Enrollment Policy
STATUS: Failed
The RPC server is unavailable.
3. The most common cause for that error, is the membership of the 'Certificate Service DCOM Access' group is incorrect, check yours and make sure it matches the one below.

4. On the CA Server launch the Certification Authority management tool and look at the properties of the CA Server itself, on the security tab make sure yours looks like this, (Domain computer and domain controllers should have the 'request certificates' rights).

5. Still on the CA Server, check the permissions on the C:\Windows\System 32\certsrv directory, authenticated users should have Read & Execute rights.

6. This is the change that finally fixed mine: In active directory users and computers, locate the Builtin container, within it there is a group called 'Users'. Make sure it contains Authenticated Users and INTERACTIVE.

7. Run a 'gpupdate /force' on your test client, and/or reboot it.

www.petenetlive.com

Sao lưu và phục hồi trong Windows

Đối với người quản trị hệ thống thì việc sao lưu và phục hồi dữ liệu là một công việc quyết định sự tồn tại của họ nói riêng và của cả công ty họ nói chung. Dữ liệu là tài sản vô cùng quí giá đối với bất kì tổ chức nào. 

A.     Back up có các dạng sau: Normal, Differential, Incremental, Copy và Daily.

1.      Normal:

ü      Back up toàn bộ dữ liệu mà ta cấu hình “job” cho dữ liệu đó.

ü      Xóa marker, nghĩa là sau khi backup xong windows sẽ ghi nhận là dữ liệu đã được back up.

2.      Differential:

ü      Chỉ back up những phần dữ liệu có sự thay đổi mà ta cấu hình “job” cho dữ liệu đó.

ü      Không xóa marker, nghĩa là sau khi backup xong windows sẽ ghi nhận là dữ liệu chưa được back up.

3.      Incremental:

ü      Chỉ back up những phần dữ liệu có sự thay đổi mà ta cấu hình “job” cho dữ liệu đó.

ü      Xóa marker, nghĩa là sau khi backup xong windows sẽ ghi nhận là dữ liệu đã được back up.

4.      Copy:

ü      Back up toàn bộ dữ liệu mà ta cấu hình “job” cho dữ liệu đó.

ü      Xóa marker, nghĩa là sau khi backup xong windows sẽ ghi nhận là dữ liệu chưa được back up.

5.      Daily:

ü      Chỉ back up những dữ liệu bị thay đổi trong ngày hiện tại mà ta cấu hình “job” cho dữ liệu đó.

ü      Không xóa marker, nghĩa là sau khi backup xong windows sẽ ghi nhận là dữ liệu chưa được back up.

B.     Sự kết hợp của các kiểu back up

Chúng ta có các kiểu kết hợp thông dụng sau:

ü      Normal + Incremetal.

ü      Normal + Differential.

ü      Normal + Differential + Copy.

Ví dụ: ta có dữ liêu sau cần back up.

Khi đó, mỗi sự kết hợp khác nhau sẽ có cách hoạt động khác nhau, sau đây chúng ta sẽ tìm hiểu từng kiểu back up đã nêu trên.

1.      Normal + Incremetal:

Ta cấu hình chúng thực hiện back up theo bảng sau:

Thứ	Hai	Ba	Tư	Năm	Sáu	Bảy
Kiểu Back up	Normal	Incremetal	Incremetal	Incremetal	Incremetal	Incremetal
File lưu trữ	N2.bkf	I3.bkf	I4.bkf	I5.bkf	I6.bkf	I7.bkf

Diển giải:

File N2.bkf sẽ chứa tất cả các dữ liệu mà ta cấu hình “job” thực hiện back up cho dữ liệu đó.

Các file: I3.bkf, I4.bkf, I5.bkf, I6.bkf và I7.bkf chỉ chứa những dữ liệu mà có thay đổi trong các ngày tương ứng lần lược từ thứ Ba, Tư, Năm, Sáu và Bảy. 

Nếu chúng ta cần phục hồi dữ liệu của ngày thứ năm thì ta se restore lần lược các file sau đây:

N2.bkf -> I3.bkf -> I4.bkf -> I5.bkf. (Restore 4 file) 

Tóm lại, ưu khuyết điểm của kiểu này như sau:

Ưu: back up nhanh.

Khuyết: resotre chậm.

2.      Normal + Differential:

Ta cấu hình chúng thực hiện back up theo bảng sau:

Thứ	Hai	Ba	Tư	Năm	Sáu	Bảy
Kiểu Back up	Normal	Differential	Differential	Differential	Differential	Differential
File lưu trữ	N2.bkf	D3.bkf	D4.bkf	ID5.bkf	D6.bkf	D7.bkf

Diển giải:

File N2.bkf sẽ chứa tất cả các dữ liệu mà ta cấu hình “job” thực hiện back up cho dữ liệu đó.

File D3.bkf chỉ chứa những thay đổi của ngày thứ Ba.

File D4.bkf chứa những thay đổi của ngày thứ Ba và Tư.

File D5.bkf chứa những thay đổi của ngày thứ Ba, Tư và Năm.

File D6.bkf chứa những thay đổi của ngày thứ Ba, Tư, Năm và Sáu.

File D7.bkf chứa những thay đổi của ngày thứ Ba, Tư, Năm, Sáu và Bảy.

Nếu chúng ta cần phục hồi dữ liệu của ngày thứ năm thì ta se restore lần lược các file sau đây:

N2.bkf -> D5.bkf. (Restore 2 file)

Tóm lại, ưu khuyết điểm của kiểu này như sau:

Ưu: back up chậm.

Khuyết: resotre nhanh.

3.      Normal + Differential + Copy:

Ta cấu hình chúng thực hiện back up theo bảng sau:

Thứ	Hai	Ba	Tư	Năm	Sáu	Bảy
Kiểu Back up	Normal	Differential	Differential	Differential Copy	Differential	Differential
File lưu trữ	N2.bkf	D3.bkf	D4.bkf	D5.bkf C5.bkf	D6.bkf	D7.bkf

Diển giải:

Kiểu kết hợp này tương tự như kiểu 2, nhưng vấn đề đặt ra là, khi chúng ta đã cấu hình sẵn sàng cho hệ thống thực hiện back up tự động các ngày trong tuần bất thình lình ngày thứ năm chúng ta được yêu cầu back up lại toàn bộ dữ liệu

Như vậy chúng ta sẽ thêm 1 “job” vào ngày thứ Năm và job này chỉ có thể là Copy vì nấu chúng ta chọn Normal thì sau khi back up xong windows sẽ xóa marker đi dẫn đến tiến trình back up “Normal + Differentil” đã cấu hình sẵn sẽ chạy sai với mong muốn ban đầu.

Dương Việt Trí

Application Pool Identities

Introduction

Whether you are running your site on your own server or in the cloud, security must be at the top of your priority list. If so, you will be happy to hear that IIS has a security feature called the application pool identity. This feature was introduced in Service Pack 2 (SP2) of Windows Server 2008 and Windows Vista. An application pool identity allows you to run an application pool under a unique account without having to create and manage domain or local accounts. The name of the application pool account corresponds to the name of the application pool. The image below shows an IIS worker process (W3wp.exe) running as the DefaultAppPool identity.

Application Pool Identity Accounts

Worker processes in IIS 6.0 and in IIS 7 run as Network Service by default. Network Service is a built-in Windows identity. It doesn't require a password and has only user privileges; that is, it is relatively low-privileged. Running as a low-privileged account is a good security practice because then a software bug can't be used by a malicious user to take over the whole system.
However, a problem arose over time as more and more Windows system services started to run as Network Service. This is because services running as Network Service can tamper with other services that run under the same identity. Because IIS worker processes run third-party code by default (Classic ASP, ASP.NET, PHP code), it was time to isolate IIS worker processes from other Windows system services and run IIS worker processes under unique identities. The Windows operating system provides a feature called "virtual accounts" that allows IIS to create a unique identity for each of its application pools. Click here for more information about Virtual Accounts.

Configuring IIS Application Pool Identities

If you are running IIS 7.5 on Windows Server 2008 R2, or a later version of IIS, you don't have to do anything to use the new identity. For every application pool you create, the Identity property of the new application pool is set to ApplicationPoolIdentity by default. The IIS Admin Process (WAS) will create a virtual account with the name of the new application pool and run the application pool's worker processes under this account by default.
To use this virtual account when running IIS 7.0 on Windows Server 2008, you have to change the Identity property of an application pool that you create to ApplicationPoolIdentity. Here is how:

1. Open the IIS Management Console (INETMGR.MSC).
2. Open the Application Pools node underneath the machine node. Select the application pool you want to change to run under an automatically generated application pool identity.
3. Right click the application pool and select Advanced Settings...
4. Select the Identity list item and click the ellipsis (the button with the three dots).
5. The following dialog appears:
6. Select the Built-in account button, and then select the identity type ApplicationPoolIdentity from the combo box.

To do the same step by using the command-line, you can call the appcmd command-line tool the following way:
%windir%\system32\inetsrv\appcmd.exe set AppPool <your AppPool> -processModel.identityType:ApplicationPoolIdentity

Securing Resources

Whenever a new application pool is created, the IIS management process creates a security identifier (SID) that represents the name of the application pool itself. For example, if you create an application pool with the name "MyNewAppPool," a security identifier with the name "MyNewAppPool" is created in the Windows Security system. From this point on, resources can be secured by using this identity. However, the identity is not a real user account; it will not show up as a user in the Windows User Management Console.
You can try this by selecting a file in Windows Explorer and adding the "DefaultAppPool" identity to the file's Access Control List (ACL).

1. Open Windows Explorer
2. Select a file or directory.
3. Right click the file and select Properties
4. Select the Security tab
5. Click the Edit button and then Add button
6. Click the Locations button and make sure that you select your computer.
7. Enter IIS AppPool\DefaultAppPool in the Enter the object names to select: text box.
8. Click the Check Names button and click OK.

By doing this, the file or directory you selected will now also allow the DefaultAppPool identity access.
You can do this via the command-line by using the ICACLS tool. The following example gives full access to the DefaultAppPool identity.
ICACLS test.txt /grant "IIS AppPool\DefaultAppPool":F For more information, see ICACLS.
On Windows 7 and Windows Server 2008 R2, and later versions of Windows, the default is to run application pools as the application pool identity. To make this happen, a new identity type with the name "AppPoolIdentity" was introduced. If the "AppPoolIdentity" identity type is selected (the default on Windows 7 and Windows Server 2008 R2, and later), IIS will run worker processes as the application pool identity. With every other identity type, the security identifier will only be injected into the access token of the process. If the identifier is injected, content can still be ACLed for the ApplicationPoolIdentity, but the owner of the token is probably not unique. Here is an article that explains this concept.

Accessing the Network

Using the Network Service account in a domain environment has a great benefit. Worker process running as Network Service access the network as the machine account. Machine accounts are generated when a machine is joined to a domain. They look like this:

<domainname>\<machinename>$,

For example:

mydomain\machine1$

The nice thing about this is that network resources like file shares or SQL Server databases can be ACLed to allow this machine account access.

What about Application Pool Identities?

The good news is that application pool identities also use the machine account to access network resources. No changes are required.

Compatibility Issues with Application Pool Identities

Guidance Documentation

The biggest compatibilty issue with application pool identities is probably earlier guidance documents which explicitly recommend that you ACL resources for Network Service, that is, the default identity of the DefaultAppPool in IIS 6.0 and IIS 7.0. Customers will have to change their scripts to ACL for "IIS AppPool\DefaultAppPool" (or another application pool name) when running on IIS 7.5 or later (see the example above for how to do this).

User Profile

IIS doesn't load the Windows user profile, but certain applications might take advantage of it anyway to store temporary data. SQL Express is an example of an application that does this. However, a user profile has to be created to store temporary data in either the profile directory or in the registry hive. The user profile for the Network Service account was created by the system and was always available. However, with the switch to unique Application Pool identities, no user profile is created by the system. Only the standard application pools (DefaultAppPool and Classic .NET AppPool) have user profiles on disk. No user profile is created if the Administrator creates a new application pool.
However, if you want, you can configure IIS application pools to load the user profile by setting the LoadUserProfile attribute to "true".

Summary

Application pool identities are a powerful new isolation feature introduced for Windows Server 2008, Windows Vista, and later versions of Windows. It will make running IIS applications even more secure and reliable.

http://www.iis.net

Troubleshoot DNS Event ID 4013: The DNS server was unable to load AD integrated DNS zones

Some Microsoft and external content have recommended setting the registry value Repl Perform Initial Synchronizations to 0 in order to bypass initial synchronization requirements in Active Directory. The specific registry subkey and the values for that setting are as follows:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Value name:  Repl Perform Initial Synchronizations
Value type:  REG_DWORD
Value data: 0

This configuration change is not recommended for use in production environments or in any environment on an ongoing basis. The use of Repl Perform Initial Synchronizations should be used only in critical situations to resolve temporary and specific problems. The default setting should be restored after such problems are resolved.

Viable alternatives include:

• Remove references to stale domain controllers.
  
  
• Make offline or non-functioning domain controllers operational.
  
  
• Domain controllers hosting AD-integrated DNS zones should not point to a single domain controller and especially only to themselves as preferred DNS for name resolution.
  
  DNS name registration and name resolution for domain controllers is a relatively lightweight operation that is highly cached by DNS clients and servers.
  
  Configuring domain controllers to point to a single DNS server's IP address, including the 127.0.0.1 loopback address, represents a single point of failure. This is somewhat tolerable in a forest with only one domain controller but not in forests with multiple domain controllers.
  
  Hub-site domain controllers should point to DNS servers in the same site as them for preferred and alternate DNS server and then finally to itself as an additional alternate DNS server.
  
  Branch site domain controllers should configure the preferred DNS server IP address to point to a hub-site DNS server, the alternate DNS server IP  address to point to an in-site DNS server or one in the closest available site, and finally to itself using the 127.0.0.1 loopback address or current static IP address.
  
  Pointing to hub-site DNS servers reduces the number of hops required to get critical domain controller SRV and HOST records fully registered. Domain controllers within the hub site tend to get the most administrative attention, typically have the largest collection of domain controllers in the same site, and because they are in the same site, replicate changes between each other every 15 seconds (Windows Server 2003 or later) or every five minutes (Windows 2000 Server), making such DNS records "well-known".
  
  Dynamic domain controller SRV and host A and AAAA record registrations may not make it off-box if the registering domain controller in a branch site is unable to outbound replicate.
  
  Member computers and servers should continue to point to site-optimal DNS servers as preferred DNS and may point to off-site DNS servers for additional fault tolerance.
  
  Your ultimate goal is to prevent everything from replication latency and replication failures to hardware failures, software failures, operational practices, short and long-term power outages, fire, theft, flood, earthquakes and terrorist events from causing a denial of service while balancing costs, risks and network utilization.

• Make sure that destination domain controllers can resolve source domain controllers using DNS (i.e. avoid fallback)
  
  Your primary goal should be to ensure that domain controllers can successfully resolve the guided CNAME records to host records of current and potential source domain controllers thereby avoiding high latency introduced by name resolution fallback logic.
  
  Domain controllers should point to DNS servers that:

• Are available at Windows startup
• Host, forward, or delegate the _msdcs.<forest root domain> and primary DNS suffix zones for current and potential source domain controllers
• Can resolve the current CNAME GUID records (for example, dded5a29-fc25-4fd8-aa98-7f472fc6f09b._msdcs.contoso.com) and host records of current and potential source domain controllers.

Missing, duplicate, or stale CNAME and host records all contribute to this problem. Scavenging is not enabled on Microsoft DNS servers by default, increasing the probability of stale host records. At the same time, DNS scavenging can be configured too aggressively, causing valid records to be prematurely purged from DNS zones.

• Optimize domain controllers for name resolution fallback
  
  The inability to properly configure DNS so that domain controllers could resolve the domain controller CNAME GUID records to host records in DNS was so common that Windows Server 2003 SP1 and later domain controllers were modified to perform name resolution fallback from domain controller CNAME GUID to fully qualified hostname, and from fully qualified hostname to NetBIOS computer name in an attempt to ensure end-to-end replication of Active Directory partitions.
  
  The existence of NTDS replication Event ID 2087 and 2088 logged in the Directory Service event logs indicates that a destination domain controller could not resolve the domain controller CNAME GUID record to a host record and that name resolution fallback is occurring. See the following article in the Microsoft Knowledge Base for more information:
  
  824449 Troubleshooting Active Directory replication failures that occur because of DNS lookup failures, event ID 2087, or event ID 2088
  
  WINS, HOST files and LMHOST files can all be configured so that destination domain controllers can resolve the names of current and potential source domain controllers. Of the three solutions, the use of WINS is more scalable since WINS supports dynamic updates.
  
  The IP addresses and computer names for computers inevitably become stale, causing static entries in HOST and LMHOST files to become invalid over time. Experienced administrators and support professionals have spent hours trying to figure out why queries for one domain controller incorrectly resolved to another domain controller with no name query observed in a network trace, only to finally locate a stale host-to-IP mapping in a HOST or LMHOST file.

• Change the startup value for the DNS server service to manual if booting into a known bad configuration
  
  If booting a domain controller in a configuration known to cause the slow OS startup discussed in this article, set the service startup value for the DNS Server service to manual, reboot, wait for the domain controller to advertise, then restart the DNS Server service.
  
  If the service startup value for DNS Server service is set to manual, Active Directory does not wait for the DNS Server service to start.

Additional considerations:

• Avoid single points of failure.
  
  Examples of single points of failure include:
  
  • Configuring a DC to point to a single-DNS Server IP
  • Placing all DNS servers on guest virtual machines on the same physical host computer
  • Placing all DNS servers in the same physical site
  • Limiting network connectivity such that destination domain controllers have only a single network path to access a KDC or DNS Server

Install enough DNS servers for local, regional and enterprise-wide redundancy performance but not so many that management becomes a burden. DNS is typically a lightweight operation that is highly cached by DNS clients and DNS servers.

Each Microsoft DNS server running on modern hardware can satisfy 10,000-20,000 clients per server. Installing the DNS role on every domain controller can lead to an excessive number of DNS servers in your enterprise that can increase cost.

• Stagger the reboots of DNS servers in your enterprise when possible.
  
  • The installation of some hotfixes, service packs and applications may require a reboot.
  • Some customers reboot domain controllers on a scheduled basis (every 7 days, every 30 days).
  • Schedule reboots, and the installation of software that requires a reboot, in a smart way to prevent the only DNS server or potential source replication partner that a destination domain controller points to for name resolution from being rebooted at the same time.

If Windows Update or management software is installing software requiring reboots, stagger the installs on targeted domain controllers so that half the available DNS servers that domain controllers point to for name resolution reboot at the same time.

• Install UPS devices in strategic places to ensure DNS availability during short-term power outages.

• Augment your UPS-backed DNS servers with on-site generators.
  
  To deal with extended outages, some customers have deployed on-site electrical generators to keep key servers online. Some customers have found that generators can power servers in the data center but not the on-site HVAC. The lack of air conditioning may cause local servers to shutdown when internal computer temperatures reach a certain threshold.

Modifying the Mail File Owner Field

Back in the day, which would be the Lotus Notes/Domino R5 days, if you needed to change the mail file owner field in a database, be it mail-in or person, it was a simple process. Open the mail file, click on Preferences – Mail – Basics, select a name from the Domino Directory, and save the Preference.
Apparently, to “prevent issues caused by the name in the Mail File Owner field not existing as a valid hierarchical name in the Domino Directory,” this behavior was changed in Release 6. The field was protected and usually required a change to the design of the mail file to allow this field to be edited.
That is a tiresome change.
If you have a mail file, or mail-in database, where you want to change the Owner field, it is as simple as creating a button and mailing it to the affected user (bad idea). I prefer using the same technique, but instead of waiting for the user to do something (click a button, in this case), open the mail file, create a button, and click it for the user.
Open the mail file.
Create a new messsage
In a blank line of the new message, click Create – Hotspot – Button. Give the button a name, in this case “ClickMe.”

Now, add some code to the button:
@SetProfileField(“CalendarProfile”;”Owner”;”<hierarchical name of user>”)
Example: @SetProfileField(“CalendarProfile”;”Owner”;”CN=Gregg Eldred/O=Acme”)

Click the green check mark, to save the code.
The button is now on a blank memo, created in the mail file of the person who has an issue with the Owner field. And, as you created the button, the field value is perfect.
Click the button.
To confirm that your code worked, open Preferences – Mail – Basics. You should see something like this:

 

There, problem solved and the user didn’t have to do a thing (that’s called a “win” in my book).

geldred.com

Row Not Found at the Subscriber - Replication Issue

When you find an issue in replication with the error “The row was not found at the Subscriber when applying the replicated command.”, first we have to get the Transaction sequence number and Command ID from the error.

This can be found at Distributer to Subscriber history in replication monitor.

Once we get the Transaction Sequence Number and Command ID we can easily drill down to the command which is causing the issue by using sp_browsereplcmds. Before to this, we have to also find out publisher_database_id.

For finding publisher_database_id, we need to make use of Transaction Sequence Number and Command ID.

Query to find publisher_database_id using Transaction Sequence Number and Command ID

select * from msrepl_commands where xact_seqno = 0x000BF8FB0003411E000400000000 and command_id=6

Once we get the publisher_database_id from the above query, then we need to execute the below query to get the command which is causing the error.

Query to find the command which is causing error

exec sp_browsereplcmds @xact_seqno_start = '0x000BF8FB0003411E000400000000', @xact_seqno_end = '0x000BF8FB0003411E000400000000', @Command_id=6, @publisher_database_id=60

Once we get the command, we can manually sync the missing data from publisher to subscriber to make the replication work fine as before.

Note: All these commands have to be run on distribution database.

 

http://www.sanssql.com