Hi, I’m Dean Paron, Product Unit Manager for Windows MultiPoint Server and today I’m excited to announce the availability of the Windows MultiPoint Server 2011 Beta.
Back in February of 2010, we launched a new product, called Windows MultiPoint Server 2010, which is designed primarily for the education market to help schools increase computing access to more students for a lower total cost. Now, schools around the world are using Windows MultiPoint Server in their classrooms, labs and libraries to give students the experience of using the latest Windows technology that will help prepare them for the workforce. Teachers and students are finding Windows MultiPoint Server to be a great way to collaborate with each other on school projects and experience Windows 7 and the power it brings to help them teach and learn. You can watch an online demo of Windows MultiPoint Server 2010 and listen to customers talk about their experiences here. Education institutions, and other organizations such as non-profits and charities, are taking advantage of the benefits of Windows MultiPoint Server, such as a lower total cost of IT ownership, and easier setup, management and use.
So what’s new with Windows MultiPoint Server 2011? We’ve been listening to customer and partner feedback and here are some of the new things you’ll find:
1. Desktop thumbnails that make it easier for teachers to orchestrate activities across the classroom, see what students are working on, and interact with student sessions. 2. Support for connecting thin clients over the LAN. This allows for virtually unlimited distances between stations. 3. The ability to string multiple MultiPoint Server “pods” and manage them from a unified MultiPoint Manager console. Great for labs and libraries where there are a large number of stations in a single place. 4. Split screen capabilities at each user station. Turn one screen into two separate stations for a new way of collaborative learning between students. 5. An ISV extensibility model based on a common SDK with the next versions of Windows Small Business Server and Windows Home Server, which enables ISVs such as learning and classroom management providers to integrate with MultiPoint Server. 6. Support for domain join to integrate Windows MultiPoint Server with your existing Active Directory infrastructure.
If your organization is struggling with providing enough computers for your users, decreasing technology budgets, limited technical support and outdated hardware and software, I encourage you to check out Windows MultiPoint Server 2010 today and to take a look at the enhancements we are thinking about for through the now available Windows MultiPoint Server 2011 beta.
Regards,
Dean Paron Product Unit Manager Windows MultiPoint Server
Download the Windows MultiPoint Server 2011 Beta and please send us feedback so we can keep improving!
[Today’s post comes to us courtesy of Shawn Sullivan from Commercial Technical Support]
Folder redirection is used to centrally store a user’s documents in a network location that would otherwise be located only on their individual client machine. In SBS environments, administrators use folder redirection as a convenient method to store this information on the server to be included in the normal SBS backup rotation.
Both SBS 2003 and SBS 2008 use Group Policy to accomplish this; however they differ significantly in their method. While SBS 2003 links a folder redirection GPO at the domain level and applies to all authenticated users, SBS 2008 links its GPO at the SBSUsers Organization Unit and includes only the specific users you assign to it through the SBS console.
Below is the SBS 2003 Small Business Server Folder Redirection GPO. This is created when you configure folder redirection in the Server Management Console and is deleted when you disable it.
Below is the SBS 2008 Small Business Server Folder Redirection Policy GPO. This is created during SBS integrated setup and is never removed.
In an SBS 2003 to SBS 2008 migration scenario, both of these GPOs will be present after the installation of SBS 2008 if folder redirection was previously enabled. As part of the post-migration steps, you will add the desired users to the Windows SBS Folder Redirection Accounts, force group policy update on all clients, and then remove the GPO created by SBS 2003 that is linked at the domain level. Users who are members of the new group will have their data automatically moved from the SBS 2003 machine to the SBS 2008 machine upon their next login. Those users who are not participating in folder redirection will have their data moved back to their local client machine upon their next login. If you attempt to move the data manually or if both SBS servers are not online during this entire process, then you will run into failures (see troubleshooting section below).
There are two locations where you can accomplish this. The first place is under Shared Folders and Websites > Shared Folders > Redirect folder for user accounts to the server
The second is under Users and Groups > Users > Redirect folders for user accounts to the server
Both locations launch the same window where you can choose which folders to redirect (Desktop, Documents, and Start Menu) and for which user accounts. When you do this, the user account is made a member of the Windows SBS Folder Redirection Accounts:
You may receive an informational message reminding you that it may take a few logins to complete the entire redirection process, especially if you are migrating folder redirection settings from SBS 2003:
The GPO consists of the following settings:
The top causes of folder redirection failure are incorrect permissions on the network share, Group Policy deployment failure, and problems with Offline Files.
Permission Issues
Permission issues usually originate from manually moving the user’s folder from one location to another, or if the administrator takes ownership of the user’s folder to gain access to the contents. To prevent the first scenario from occurring, use the Move Users’ Redirected Documents Data wizard . A typical error you will receive on the client machine will be something like this:
Event Type: Error Event Source: Folder Redirection Event Category: None Event ID: 102 Date: Date Time: Time User: Domain\User Computer: Computername Description: Failed to perform redirection of folder My Documents. The files for the redirected folder could not be moved to the new location. The folder is configured to be redirected to \\ servername \ sharename \%username%. Files were being moved from C:\Documents and Settings\ user \My Documents to \\ servername \ sharename \ user . The following error occurred: The security descriptor structure is invalid.
If you suspect that you are in this situation, verify the following:
Group Policy deployment issues
There are numerous potential causes to Group Policy deployment failures, use the checklist below to identify the most common:
Note: These first three bullet points are usually caused by network configuration error of the client, server, or both. For the server, run the SBS BPA to identify these issues. On the client, make sure the interface it’s using to communicate with the server has a valid IP address with the correct subnet mask and that it’s using the SBS server as it’s only DNS server.
Offline Files
There are certain circumstances that will result in Offline Files preventing the client from reaching network shares on the server. One such issue that we run into frequently is documented in the following KB article:
274789 The Folder Redirection Feature Does Not Function
http://support.microsoft.com/default.aspx?scid=kb;EN-US;274789
Usually the resolution to these cases is to reset the Offline File cache on the client and logging off and back onto the domain.
[Today’s post comes to us courtesy of Wayne Gordon McIntyre from Commercial Technical Support]
This case originally started out with the SQL team, since it was an issue with installing SQL Server 2005 Express edition. However, they were trying to install on an SBS 2003 server and the SQL engineer correctly determined that this was an issue with the O/S and not the SQL installer itself. The SQL engineer decided to engage an escalation resource on the SBS team to have a look. The error we were seeing when trying to install SQL was
Since the error referred to the logs for more information we also looked in the SQL Setup log, searched on Return Value 3 (Return Value of 3 in MSI logs indicates a failure). In the logs we saw we were trying to make a connection to the database to run a configuration script but the connection failed. We also know that with SQL Server 2005, connections to the database are made over a secure encrypted connection by default (this is important later). Output from the log is below.
SQL_ERROR (-1) in OdbcConnection::connect sqlstate=08001, level=-1, state=-1, native_error=233, msg=[Microsoft][SQL Native Client]Shared Memory Provider: No process is on the other end of the pipe.
sqlstate=08001, level=-1, state=-1, native_error=233, msg=[Microsoft][SQL Native Client]Client unable to establish connection
Error Code: 0x800700e9 (233) Windows Error Text: No process is on the other end of the pipe. Source File Name: lib\odbc_connection.cpp Compiler Timestamp: Fri Jul 29 01:13:53 2005 Function Name: OdbcConnection::connect@connect Source Line Number: 148
---- Context -----------------------------------------------
Connecting to SQL Server ExecuteSqlCommands Originial error was 800700e9 (233) cript SqlScriptHlpr
Unfortunately this didn’t give us much more information than we already had from the error shown during setup. Next, in our search for information, we went to the event logs, hoping for something more there. We did get an MsiInstaller Event, but as you can see below, it is more of the same.
At this point, I decided to not troubleshoot SQL anymore, and to look for other things that may be failing. Since we know the connection is being attempted over SSL, I tried making SSL connections over the internet to SSL sites. This worked without an issue, I then tried to make an SSL connection to the server itself by going to https://localhost/exchange and it failed to connect. I tried a few other sites hosted on the server and even created my own and made sure it had a good cert and it also failed. So we now know for sure that SSL on the server side is a problem.
At this point I wanted to dig a bit deeper into why SSL connections to the server was failing, for this I used a tool called SSLDiag (publically available tool from Microsoft.com IIS 6 only). When launching SSLDiag it performs an initial diagnostic of your IIS sites that are using SSL. This did not reveal any errors, however you can also right click on one of the sites and simulate the SSL handshake.
After clicking Simulate SSL Handshake the output received as follows.
So now I have an error code to work with. To determine the meaning of this error code, I used "err" (another publically available tool from Microsoft.com).
At this point I decided to compare a working machine (my own server) against his server by taking side by side procmons of a site that is configured with SSL. This is a common technique we use in support to determine how something should work, so we can fill in the missing pieces on the machine that is not working. On the top is the broken server and on the bottom is a working server, the key difference is that on the working server LSASS loads SChanell.dll and the broken server does not (but we also can determine from the procmon that Schanell.dll is fine because on the client piece of the communication thru internet explorer it DOES load schannel.dll)
Now I need to figure out why Schannel is not loading, my first assumption which turned out to be correct is that it is somehow disabled on the server end. So I put my searching skills to use by searching on "SChannel Disabled" in the Microsoft knowledge base and the first hit was:
187498 How to disable PCT 1.0, SSL 2.0, SSL 3.0, or TLS 1.0 in Internet Information Services
http://support.microsoft.com/kb/187498/sl
And sure enough under the key HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHannel\Protocols\SSL 3.0\Server a DWORD of Enabled existed and was set to 0 (this also existed under the TLS 1.0 Protocol Key). I deleted the Enabled DWORD, rebooted the server and I can now access SSL websites hosted on the server. However, the initial reason for the case was still for the SQL installation, since we knew at the beginning it was failing to make a connection to the SQL Server instance over a secure connection, we figured that the SQL install should now work. We attempted the SQL installation again and it completed without an error and the issue was resolved.