The Microsoft iSCSI Software Target 3.2 is designed for Windows Storage Server 2008 and it’s only distributed to storage OEM partners and MSDN Subscriptions. The iSCSI target MSI package will check for Windows SKU and show error message “Installation is not supported on this operating system.”if it’s not installing on Windows Storage Server.
To install the iSCSI target on other Windows Server SKU for testing purpose, the MSI database can be modified to remove the Launch Condition.
IMPORTANT: This is never a supported configuration and do it at your own risk.
- Install the tool “Orca” in Windows SDK. See http://support.microsoft.com/kb/255905
- Open the iscsitarget.msi with Orca, look for the IsSupportedSKU condition in LaunchCondition table.
- Remove the IsSupportedSKU condition
- In Tools->Options->Database, make sure the “Copy embedded streams during “Save As”” is checked.
- Click File->Save As to export the modified MSI package.
I’ve been awaiting for the Synology NAS firmware upgrade with iSCSI support so I can try out Windows Server 2008 failover clustering on my Hyper-V box. The good news is the DSM 2.2 BETA is out with iSCSI but it is IET based which lacks SCSI-3 persistent reservation support required by Windows Server 2008 cluster. Same problem for some other software iSCSI targets, e.g. OpenFiler
Problem: The following error is shown in Windows XP Remote Desktop Connection when connecting Windows Vista / Windows Server 2008 requiring Network Level Authentication.
Solution: Enable CredSSP Security Service Provider in Windows XP SP3 which is disabled by default.
- Install Windows XP SP3
- Follow the instructions in KB951608 to turn on CredSSP http://support.microsoft.com/kb/951608/
To start with something simple I’m building up a 2-tier CA hierarchy incorporating an offline root CA and and issuing Windows Server 2003 Enterprise CA.
Some notes on my Root CA setup:
- Install Windows Server 2003, Standard Edition is good enough for an offline CA.
- Workgroup only, DO NOT join Domain.
- Think twice on the Computer Name before starting CA installation, computer cannot be renamed afterwards.
- IMPORTANT! Create CAPolicy.inf in C:\WINDOWS (or %SYSTEMROOT%) to specify empty CRL distribution point and AIA.
Signature= “$Windows NT$”
- Install Certificate Services only and do not install IIS and other services to minimize attack surface. You don’t need web enrollment for this offline CA.
- Use custom settings to specify key length as 4096 bits and 5 years validity. (Watch out for Domino root certificate key length support, use 2048-bit if any SubCA is going to issue certificate for S/MIME for Domino 6 & 7. More on MyKB)
- After installation, use “certutil –setreg ca\[name]” to set issuing validity timespan and default container distinguished name referenced by CDP and AIA LDAP URL.
- Config CA’s CDP and AIA locations. The objective is to use external FQDN instead of computer name for the HTTP URL and to make it comes before LDAP URL.
- Remove the default URLs except the local disk location and add back the followings URLs
- Config CRL publication interval and make sure Delta CRL is disabled. (Which an interval of 180 days is already specified in the CAPolicy.inf file).
- Publish the CRL and examine the CDP location. Make sure the DSConfigDN registry is correctly setup and you are not seeing “DC=UnavailableConfigDN namespace”in the LDAP URL.
OK, the root CA is now ready. The next would be the issuing enterprise CA.
Problem: For user logs on to multiple machines with autoenrollment enabled, each machine will generate a new set of private and public keys for the user since user’s existing certificates do not exist in the local certificate store.
Solution: Configure Credential Roaming supported in Windows Server 2003 SP1 Administrative Template.