Optical Storage What is IMAPI 2.0
The Microsoft Windows image mastering API enables applications to stage and burn images to CD and DVD optical storage media. Other disc-like media that lay down images in the same manner can also use this API.
What’s New in IMAPI 2.0
MAPIv2FS Multiboot
Currently, the implementation of IMAPIv2FS only supports single boot entry, thus only one boot image may be written on a disc. The ability of writing multiple boot entries / boot images is required for the EFI/UEFI support. It is additionally a feature of its own that enables for instance a boot media with boot straps for both Windows XP and Windows Vista.
To support multiple boot entries / boot images, the following functionalities are supported by IMAPIv2FS:
Ability to accept input of multiple IBootOptions.
IBootOptions is an implemented interface to remember the boot entry attributes and boot image associating with the boot entry. By allowing application input multiple IBootOptions, IMAPIv2FS can remember them and later on write the boot entries and boot images on physical media.
Ability to store the information of multiple IBootOptions.
This includes storing boot entry attributes, boot image, calculating the boot image size and calculating the boot image starting sector.
Ability to organize multiple boot entries and boot images into disc image.
IMAPIv2FS should be able to extract information from stored IBootOptions, convert the information in correct layout and put it into the disc image for writing.
IMAPIv2FS supports a given set of programming languages. The new interfaces must preserve the same set of programming languages.
Who Should Use IMAPI2FS Multiboot Feature Enhancements?
The scenarios are targeted at application developers and ISVs.
Benefits of the new features in IMAPI 2.0
The ability of writing multiple boot entries / boot images for the EFI/UEFI support. Enables a boot media with boot straps for both Windows XP and Windows Vista.
Scenario 1 – Create a single startup disk using the IMAPIv2 APIs Goal of the scenario:
To create a single startup disk using the IMAPIv2 APIs.
Specific hardware requirement:
DVD or CD burner.
Prerequisites or specific configuration for the scenario:
Must provide boot image.
Step-by-step scenario description:
1. Have a boot image ready.
2. Use IMAPIv2 APIs to write the boot image to disc.
Expected results:
The single boot disc is successfully created.
Exceptions:
None.
Scenario 2 – Create a Multiboot Disk using the IMAPIv2 APIs Goal of the scenario:
To use the new interfaces to create a multiboot disc.
Specific hardware requirement:
DVD or CD burner.
Prerequisites or specific configuration for the scenario:
Must provide a boot image.
Step-by-step scenario description:
1. Have a boot image ready.
2. Use IMAPIv2 APIs to write the boot image to disc.
Expected results:
You should be able to add up to 32 images to a single disc.
Limitations:
Boot Entries Count
As our implementation limits the boot catalog to be one sector (2048 bytes) and every boot entry needs 64 or 32 bytes (possibly 32 bytes for section header and 32 bytes for the entry itself), we put the limitation of boot entries as 32. This means that IMAPIv2FS will support maximum 32 boot entries for one disc. As we expected no more than single-digit count of boot entries in usual scenarios, this is more than enough.
Boot Image
Boot image must be supplied to IMAPIv2FS by outside applications who invoke IMAPIv2FS to build the bootable disc. IMAPIv2FS will not generate boot image by itself. In particular, IMAPIv2FS will not provide authoring of FAT partition image for EFI/UEFI bootable disc.
Section Entry Extension
Section Entry Extension is not supported by IMAPIv2FS at this stage. There is no industry requirement for this field currently and the implementation of Section Entry Extension support differs between BIOSes.
Networking What Is Wireless management support for 802.11n?
IEEE 802.11n is a new standard that is still under draft development. 802.11n builds upon previous 802.11 wireless LAN standards by adding Multiple-Input Multiple-Output technology which enables it to achieve a very high throughput.
Microsoft Windows Vista SP1 adds the support of 802.11n by which a user can plug in an 802.11n Draft 2.0 compatible wireless adapter and connect to an 802.11n Draft 2.0 compatible network. The ‘Connect to a network’ dialog window and ‘netsh’ commands will now identify 802.11n networks and will display their information.
What’s New in Wireless management support for 802.11n? Radio type support in ‘Connect to a network’ dialog
In ‘Connect to a network’ dialog, if the user hovers mouse over an 802.11n capable network (example is an access point supporting both 802.11a & 802.11n), the popup tooltip shows the radio type as ‘802.11n’. If the user hovers mouse over a network containing multiple access points supporting different radio types, the popup tooltip will show all radio types. For example, if one access point supports 802.11a and another one supports 802.11n, while both have same network name, the popup tooltip shows the radio type as ‘802.11an’
Radio type support in netsh commands
The command “netsh wlan show networks mode=bssid” shows detailed information on access points such as radio signal, radio type, channel number, rates for available networks. With 802.11n feature, correct radio type will be displayed. For example, for a network containing a single access point supporting 802.11a and 802.11n, ‘802.11n’ will be displayed as radio type for the access point. For a network containing two access points with one supporting 802.11a and the other supporting 802.11n, ‘802.11n’ will be displayed as the radio type for the 802.11n access point (previously this was appearing as Radio Type: Unknown)
Previously, when “netsh wlan show driver” command was run on a system with an 802.11n adapter, the ‘Radio types supported’ was displayed as ‘Unknown.’ With the 802.11n feature, the ‘Radio types supported’ is correctly displayed as ‘802.11n’
Accurate 802.11n channel number
Previously, when netsh commands were run, the channel numbers shown in command “netsh wlan show networks mode=bssid” and “netsh wlan show driver” were meaningless. With the 802.11n feature, the netsh commands now display correct channel numbers.
Who Should Use Wireless management support for 802.11n feature enhancements?
This guide is targeted at Wireless LAN users who use 802.11n networks.
Benefits of new features in Wireless management support for 802.11n Wireless Management support for 802.11n
This feature enables existing wireless management to support the new radio type of 802.11n. ‘Connect to a network’ dialog and netsh commands correctly reflect the radio type and channel number.
Key Scenarios Scenario 1 – Connecting to 802.11n network
Mike’s wireless adapter is 802.11n capable and his enterprise wireless network (network SSID is “CORPWLAN”) is also 802.11n capable. He opens ‘Connect to a network’ dialog and sees “CORPWLAN” is in the available list. He hovers the mouse over “CORPWLAN”. A tooltip pops up showing the radio type is “802.11n” and signal strength as excellent. He then double clicks this network and connects to it.
Scenario 2 – Query supported radio type
Mary installs an 802.11n capable wireless adapter. She opens command prompt and runs command “netsh wlan show driver”. The command output shows the radio types supported: 802.11g, 802.11b, 802.11n.
Scenario 3 – Query Channel number
Terry uses his 802.11n capable wireless adapter to connect to his enterprise 802.11n wireless network. He opens command prompt and runs command “netsh wlan show network mode=bssid”. The command output shows a list of access points reflecting correct radio types and channel numbers.
Known Issues for scenarios
Pre 802.11n Draft 2.0 versions wireless adapters, access points may not work correctly.
What Is Network Diagnostics Framework?
The Network Diagnostics Framework (NDF) is complimentary to the Windows Diagnostics Infrastructure. It coordinates the execution of Helper Classes that diagnose/repair connectivity issues, and presents the diagnostics/status to the user.
Helper Class – Class instantiated by the Network Diagnostics Framework that understands the health of a specific component. If the component has low health, the helper class will provide repair options and the root cause of the problem.
What’s New in NDF
New Helper Class : SMB Helper Class
The SMB Helper class provides an entry point for diagnosing possible higher level issues like File Sharing problems. Once the issue is confirmed, either repairs are provided by the Helper Class itself, or hypothesis are returned for other lower level helper classes to continue diagnosis.
Who Should Use NDF enhancements?
All users can use SMB Helper Class as a part of NDF to diagnose and repair file sharing problems.
IT support professionals can use it to diagnose and repair customer’s issues.
Application developers can use it to handle file sharing issues from their applications.
SMB Helper Class
Users, IT professionals, developers, can use NDF to diagnose and repair file sharing problems along with network issues handled by other helper classes.
Key Scenarios Scenario 1 – Not Existing Server Goal of the scenario:
To diagnose the failure when user is trying to access a server that does not exist.
Specific hardware requirement:
None.
Prerequisites or specific configuration for the scenario:
None.
Step-by-step scenario description
1. Open the Run window.
2. Type a non-existing server name.
3. Click the OK button.
4. Click the Diagnose button.
Expected results
Error message reading “Windows cannot find NonExisitngServer” message with details about how to possibly resolve the error.
Exceptions:
None.
Scenario 2 – Existing Server but not existing share: Goal of the scenario:
To diagnose the failure when user is trying to access not existing share on existing server.
Specific hardware requirement:
None.
Prerequisites or specific configuration for the scenario:
Need to be able to access the remote server.
Step-by-step scenario description
1. Open the Run window.
2. Type: \\.
3. Click the OK button.
4. Click the Diagnose button.
Expected results
Error stating that Windows can find the server, but not the share.
Exceptions:
None.
Scenario 3 – Almost Right Share Goal of the scenario:
To diagnose the failure when user misspells the share name.
Specific hardware requirement:
None.
Prerequisites or specific configuration for the scenario:
Need to be able to access remote share.
Step-by-step scenario description
1. Open the Run window.
2. If your remote share path is \\server\share then type \\server\share1 or \\server\shar.
3. Click the OK button. You will receive an error message.
4. Press the Diagnose button.
Expected results
You should get a message explaining that Windows could not find that exact server and share name but that it found something similar that may be correct.
What Is DNS suffix search list through DHCPv6?
Name resolution for short names is not working correctly for IPv6 for non-domain-joined machines when there are multiple domains in a domain forest because DHCP can provide only 1 DNS suffix through DHCP. This feature adds support for a DNS suffix search list so that multiple DNS-suffixes can be provisioned to Windows clients through use of DHCPv6 option 24.
What’s New in DNS suffix search list through DHCPv6
Added support for multiple Domain suffixes in DHCPV6.
With this feature, the client can have multiple Domain Suffixes in the Domain Search list. These suffixes can be configured as option 24 of DHCPV6 on a DHCPV6 server.
Who Should Use DNS suffix search list through DHCPv6 feature enhancements?
IT planners and analysts who are evaluating the product.
Enterprise IT planners and designers.
Early adopters.
Security architects who are responsible for implementing trustworthy computing.
Benefits of new features in DNS suffix search list through DHCPv6
Name resolution using short name for IPV6.
Name resolutions using short names can be done by IPv6 for the following users in a corporate network scenario where there are multiple domains:
Home machines which VPN into the corpnet.
Roaming guest laptops on the corpnet accessing corpnet resources (e.g., many companies have vendors & consultants who bring their laptops and need to access the local resources).
Non-domain-joined laptops on the network (e.g., Windows customers without AD, student laptops, etc).
Key Scenarios
 Note
Both these scenarios below are applicable for Physical as well as VPN Interfaces.
Scenario 1 – Only one domain suffix configured for option 24
Get the domain name for client configured as option 24 of DHCPV6.
Prerequisites or specific configuration for the scenario
DHCPV6 Stateful server joined to a domain (e.g., server1.com)
V6 scope configured (e.g. as 3ffe::)
Option 24 configured (e.g., as server1.com)
Step-by-step scenario description
1. Enable V6 stateful mode on the client.
2. Verify the output of ipconfig /all.
Note
The client should have the ipv6 address.
1. Verify that the configured domain (server1.com) appears in the DNS Suffix Search list, Connection -specific DNS suffix and Connection -specific DNS suffix search list.
2. From the test client machine, ping a test machine registered in the server1.com domain. For example, ping where is the test machine.
Note
You can verify this with the DNS packets captured using Netmon.
Expected results
The test client should try pinging it through test.server1.com and the ping request should succeed.
Scenario 2 – Multiple domain suffixes configured for option 24 Goal of the scenario
Get multiple domain suffixes for the client as option 24 for DHCPV6.
Prerequisites or specific configuration for the scenario
DHCPV6 Stateful server joined to a domain (e.g., server1.com)
V6 scope configured (e.g., 3ffe::)
Option 24 configured as server1.com, server2.com, server3.com, in order.
Step-by-step scenario description
1. Enable V6 stateful mode on the client.
2. Verify the output of ipconfig /all.
Note
The client should have the ipv6 address.
1. Verify that the configured domains (server3.com, server2.com, server1.com) appear in DNS Suffix Search list in order (Connection -specific DNS suffix should be the first domain suffix). In this case it should be server3.com and the Connection -specific DNS suffix search list should contain server3.com, server2.com, server1.com.
2. From the test client machine, ping a dummy machine registered in server1.com domain. For example, ping where is the hostname of the test machine.
Expected results
The test client machine should ping the dummy machine by appending the domain suffixes as per the order in DNS suffix search list.
In effect, the client machine will first try with test.server3.com, but find that the test machine is not present in the domain. After that failure, the client machine should fallback to the next suffix present in the DNS Suffix Search list.
In this case, in the third trial it will succeed.
You can verify this with the DNS packets captured using Netmon.
Exceptions
When you try with multiple suffixes, make sure that all the domains are present in the forest, otherwise the DNS server will return a server failure for non-existing domains instead of sending a name error, which takes some time. So in between tries the DNS client may timeout and you would not see that the client is not getting fall backed to next suffix.
What Is Single Sign On for Wired Networks?
Enterprises utilize various means of authentication to obtain access to either a corporate machine or a corporate network. The growing emphasis on network security has prompted the use of layer2 network authentication methods such as 802.1X over wired as well as wireless LANs.
This shift towards requiring authentication prior to network connection establishment challenges many of the assumptions that earlier versions of Windows have been written to, e.g., the device may not always be connected to the network, credentials required for network authentication may be different than standard logon credentials, network connectivity may change when the user logs on.
The challenge for us is in executing layer2 network authentication at the appropriate time given the configuration of the defined network security policy while at the same time simply and seamlessly integrating with the user’s sign-on experience.
Single-Sign-On for Wired Networks (Wired SSO) is a feature that enables IT administrators to configure wireless/wired network profiles which execute 802.1X network authentication prior to (or immediately after) local user logon.
What’s New in Wired SSO?
The wireless Single-Sign-On feature in Windows Vista enables enterprise IT administrators to configure wireless network profiles which execute 802.1X network authentication prior to (or immediately after) local user logon. The new capability for Windows Vista SP1, Wired SSO, will extend that functionality to 802.3 (Wired) Ethernet networks.
Change password over SSO
One of the changes made is to add the ability for a user to change his/her SSO password, through SSO, as opposed to winlogon/desktop. This feature did not exist in Windows Vista. This has been added at the explicit request of partners and enterprise customers.
The ability to correct a wrong password entered for SSO
Another one of the changes made is to add the ability for a user to correct his/her SSO password, when they enter his/her password incorrectly. This feature did not exist in Windows Vista. This has been added at the explicit request of partners and enterprise customers.
Who Should Use Wired SSO feature enhancements?
IT planners and analysts who are evaluating the product.
Enterprise IT planners and designers.
Early adopters.
Security architects who are responsible for implementing trustworthy computing.
Benefits of new features in Wired SSO
SSO for Wired
The Single-Sign-On feature for wired will enable many scenarios such as getting GPO updates, running Log-On scripts, and wireless Bootstrap which require network connectivity prior to user logon and are essential for enterprise customers over wired networks. Wired Single-Sign-On delivers a seamless user experience and can be used on wired media types in which customers deploy layer2 authentication methods
Change password over SSO
Previously users were not able to change their SSO network passwords at logon time, if their
passwords had expired. This ability has been added at the explicit request of partners and enterprise customers. As a result of the change the user can now change his/her SSO network password at logon time.
The ability to correct a wrong password entered for SSO
Previously if a user entered his/her SSO network logon password incorrectly, SSO would fail without providing the user with a chance to correct his / her password. With this change for Windows Vista SP1, the user will be able to correct an incorrect password for SSO credentials.
Key Scenarios Scenario 1 – SSO over Wired:
The IT department requires that all wired devices require layer2 authentication (802.1X, WPA, WPA2) to succeed prior to access to the network. The IT admin configures the network to require user name/password access for both Winlogon Credentials as well as user name password for authenticated network access. The user launches/opens the LogonUI, and is prompted for a single user name and password. The user enters the credentials and is sequentially authenticated to the network and then the domain. The specific hardware requirement is a network that supports 802.1x authentication. The user must have a wired sso profile applied. See the Notes section below for a sample profile.
Step-by-step scenario description
1. Apply an SSO wired profile.
2. Logoff/ Logon.
3. Check event logs to ensure sso occurred.
Scenario 2 - Change Password over SSO
A user’s network logon password has expired. When the user goes to logon to the network/machine a change password screen will be invoked, and the user will be able to change his/her sso logon password. No specific hardware requirement. The user must have a wired/wireless sso profile applied. See the section below – A1 & A2 for a sample wired /wireless profile.
Step-by-step scenario description
1. Ensure the user’s credentials are set to expired.
2. Apply an SSO wired/wireless profile.
3. Logoff and then log back on to the computer.
4. User should be prompted for a password changed for SSO credentials.
5. User should be able to change password successfully.
Scenario 3 - The ability to correct a wrong password entered for SSO
A user incorrectly enters his/her SSO network logon password. A screen to correct the user’s SSO password will be invoked, and the user will be given a chance to correct his/her SSO password. No specific hardware requirement. The user must have a wired/wireless sso profile applied. See the section below-A1 & A2 for a sample wired /wireless profile.
Step-by-step scenario description
1. Apply an SSO wired/wireless profile.
2. Logoff and then log back on to the computer.
3. At the Logon screen enter the SSO password incorrectly.
4. The user should be prompted to correct the SSO password.
5. The user should be able to logon with the corrected SSO password.
Known Issues for scenarios
None.
A-1: Wired SSO Profile
false
true
true
3
machineOrUser
preLogon
50
25
0
0
0
A-2 : Wireless SSO Profile
sso
SSOSSID
false
ESS
auto
true
WPA2
AES
true
true
preLogon
60
true
25
0
0
0
| 