PeterH

Interesting thread. We are considering trialling RT devices with a small number of students for them to use at school and take home. Agree with what people have said about the Pro devices being more versatile, but they are likely to also be a lot more expensive. The RT devices are expensive enough as it is. As I see it there are several advantages to these RT devices: Office 2013 built in, no need to buy extra licenses Remote Desktop client built in, can therefore run other software if needed Can't install software except via the Windows app store - no worries about students installing unlicensed or other undesirable software No malware or viruses (yet) as it can't run x86 binaries Battery life much better than x86-based laptops or tablets

We had the same problem with the SmartBoards - check your GPOs - User Config | Policies | Administrative Templates | Windows Components | Tablet PC | Touch Input | Turn off Tablet PC touch input - make sure this is either off or not configured.

Yep it appears to be a DNS problem, it can't resolve relay.inthehive.net or any other inthehive.net subdomain. Have reported it to the OH helpdesk who were very pleasant and helpful but didn't seem to take on board that it's a DNS problem. No outbound email though until they've fixed it.

If you're using VBScript you can do the following to get the user name, computer name and time logged on: Dim wsShell, ComputerName, UserName, LogonDateTime Set wsShell=CreateObject("Wscript.Shell") ComputerName=wsShell.ExpandEnvironmentStrings("%ComputerName%") UserName=wsShell.ExpandEnvironmentStrings("%UserName%") LogonDateTime=now() We do something very similar to what you're looking at. We just run a vbscript in a logon and logoff script to record user name, computer name and date/time into a text file. I can post the whole code if you're interested.

When you build a machine the RM way, using a build disk, it's a brand new installation of Windows. But if you're using an imaging tool like WDS or Fog, it's a clone of a previous installation. The best-practise is that sysprep is used to strip out SIDs and various other things from that original installation. Perhaps there is some documentation somewhere about exactly what sysprep changes. As far as I know, the RM tool doesn't do anything like that.

Sorry forgot to say, we use WDS to capture and deploy the images which does require the machine to be sysprepped before it can be captured. Not sure about Fog as I've never used it. But I think best-practise is to sysprep before cloning anyway.

Yes, we do something similar to that. Only thing is I'm not sure if you'll be able to sysprep the machine after running the commisioning tool. Or if the commissioning tool will continue to run properly after a sysprepped image has been loaded. What we do is to install the commisioning tool but not actually run it and then place a shortcut to it on the desktop. Then sysprep the machine and capture the image. Then to build a machine, just load the image, click the icon to launch the commissioning tool and you're away. We've done that for ages with laptops that we couldn't be bothered to build in the normal RM way.

Sadly it appears not. When you set up a deployment you can specify whether it should run when a user is logged out, logged in or both. The problem is that there is nothing I can see to prevent a user from logging in whilst an installation is in progress. And there is no visual indiciation on the screen that anything is happening. For some things that may not matter too much, but there are some installations that absolutely must finish before the user logs in and starts using their computer. Sims upgrades for example. You can set up deployment windows which are timeslots during which software installations will take place. You can use WOL to start up computers overnight and update software for example. That's fine up to a point, but if the computer is not actually on-site (e.g. a laptop) it's not going to work. One other thing you can do is to make application deployment part of a task sequence, so that it will happen as part of a new installation. If you do that, the tasks will complete before the login screen is displayed and there's a nice progress bar on screen that shows what's happening. That's fine for a new OS deployment and seems to work quite well. You can use a task sequence to deploy additional applications to an existing OS, but still no way of preventing users from logging on during installation as far as I can see. We've been looking at SCCM 2012 for a few days now with a view to using it for software deployment. But this is a real show-stopper for us. It can do some clever things, but there are other simple things that seem to be missing. Unless anybody knows differently.

What you want to do is possible but a bit fiddly to set up. Some prerequisites: Windows XP SP3 Remote Desktop Client 6.1 To start with, you need to enable CredSSP support. This is done in the registry as follows. Note that this only works on XP SP3! Make the following registry changes: HKLM\SYSTEM\CurrentControlSet\Control\Lsa Security Packages – APPEND tspkg HKLM\System\CurrentControlSet\Control\SecurityProviders Security Providers – APPEND , credssp.dll (the comma is important) To veryify that this is working, open the remote desktop client mstsc.exe. Right-click in the title bar and choose About. It should say Network Level Authentication supported and Remote Desktop Protocol 6.1 supported. The next step is to enable delegation of credentials. This allows you to specify the RDS servers to which the client will delegate credentials. This can be done through group policy or alternatively, it can be done in the registry. You can find out more about credentials delegation here - Description of the Credential Security Support Provider (CredSSP) in Windows XP Service Pack 3 The group policy setting will work on XP SP3 clients but to edit it you will need to use the group policy management console on either Vista/7/2008 Method 1 – Group Policy Computer Configuration | Administrative Templates | System | Credentials Delegation Allow Delegating Default Credentials – Enabled Add your RDS servers to the list like this: TERMSRV/my-rds-server-01 TERMSRV/my-rds-server-02 TERMSRV/my-rds-server-03 etc... If you have more than one RDS server, you will need to add them all into the list above. Alternatively, you can use wildcards, so you can do something like *.mydomain.internal or to allow delegation to ANY RDS server in any domain, just use TERMSRV/* Concatenate OS defaults with list above – ticked If your RDS servers require NTLM authentication, you will need to enable Allow delegating default credentials with NTLM-only server authentication and configure it as above Method 2 – Registry The group policy settings above correspond to the following registry entries: Path: HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation Name: ConcatenateDefaults_AllowDefault Type: REG_DWORD Data: 1 Name: AllowDefaultCredentials Type: REG_DWORD Data: 1 Path: HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation\AllowDefaultCredentials Name: 1 Type: REG_SZ Data: TERMSRV/my-rds-server-01 This contains the list of your rds servers. If you have more than one you need to add them all or just use TERMSRV/* If your RDS servers require NTLM authentication, you will need to make the following registry settings as well: Path: HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation\AllowDefCredentialsWhenNTLMOnly Name: 1 Type: REG_SZ Data: TERMSRV/my-rds-srver-01 Again, this contains the list of your rds servers. If you have more than one you need to add them all or just use TERMSRV/* There’s some more information here which might be helpful

Can't answer all your questions about backing up VMs using DPM, but some significant improvements have been made to the performance of dynamically expanding VHDs in Server 2008 R2. In fact so much so that I believe dynamically expnding VHDs are now considered perfectly adequate for all but the heaviest workloads. We decided to go for dynamically expanding VHDs for our server VMs when we started to virtualise last year and I've not seen any performance issues that would indicate a problem with this. There is a very interesting whitepaper availbale from Microsoft - here - that goes into a lot more detail and compares performance of dynamically expanding VHDs between server 2008 and r2 Also according to this article, you can expand the max size of a dynamically expanding VHD. Never tried it though.

OK that's understandable. CC3 is a bit different to plain vanilla XP. It is in fact rather good once you get used to it, although it's getting a bit old now. 1. There are no local accounts and even the local administrator account is disabled. The standard RM login screen doesn't allow you to login locally anyway. The behaviour off-line is determined by the "Type of Workstation" option against the computer account in the management console. If this is set to Personal or Shared Laptop, it will allow you to login using cached credentials (that is, you have to have logged into the domain at least once) 2. Yes, you have to allocate packages as yuo have done, but you also have to allocate icons to the start menu. This depends on how you've created your packages. If you done it the 'RM way', then in your package folder you will have a Shortcuts folder containing the icons that are available for that program. For example: Package Name Shortcuts Package Name Shortcut1.lnk Shortcut2.lnk etc... If you have got your packages set up like this, you can go into Resources | Program Sets in the management console. The program sets are simply the folders on the start menu. Opening one of these up will allow you to choose your package in the left-hand side of the screen and it will then show you the shortcuts that are associated with that package. You then simply select the shortcuts you want to display in that folder. If you haven't got your package set up like that, you can make any shortcut available by copying it into \\your-server-name\rmdelivery\Group Resources\Shortcut Bank. These can then be selected by choosing Source: Shortcut bank in the Program Sets properties screen in the management console. Manual installation of programs is no problem - just login as an admin, do your install and then copy the shortcut into the shortcut bank folder as described above. Then go into the management console, open program sets, open the program set you want the icon in, choose source: Shortcut Bank and then you should see the shortcut you need. Copying icons onto the All Users desktop won't work.... RM have changed the location of this to c:\documents and settings\all users\shared desktop. Don't know if icons on there will show up for all users though... never tried it. Far better to deliver the icons to the start menu using one of the methods described above. 3. Start Menu gets delivered on login from \\your-server-name\rmdelivery\Group Resources\Programs. The RM Desktop Agent is the process I think that does this. It will only display shortcuts that resolve (ie only programs installed on that computer) The user profiles are stored in \\your-server-name\rmusers$\[userFolder]\Profiles. They are standard windows roaming profiles. Standard student users won't be able to see anything you copy onto their desktop as they don't have access to the desktop. Advanced users or Advanced Staff Users should be able to (check the User "Type of User" option again the user object in the management console) Would STRONGLY recommend against storing stuff on the desktops for Advanced Users - you may well suffer from profile bloat that will cause problems with slow login times. 4. Drive mappings are set against the computer object in the management console, not against the user object. You can find the drive mappings listed there. Keep in mind that some drives are hidden for Standard users - for example P:, Q:, L: etc. Not sure why you aren't able to display the user properties though. Try running the rm management console directly on the server, rather than on a workstation, or try it on a different machine. Never had that problem before. Perhaps try restarting the world wide web publishing services on your server. Finally, see if the school have got a copy of the CC3 administrator's guide. That will tell you most things you need to know.

Try this: c:\windows\microsoft.net\framework\v4.0.xxxxx\aspnet_regiis.exe -i -enable

It depends if you are planning to cluster your Hyper-V servers or not. If not, then I can't think of any important reason why it would need to be a domain member. If you are clustering, using multiple physical hyper-v servers, then they will need to be domain members. You can't cluster them if they're not. In which case, you would need at least one physical domain controller. We haven't got as far as virtualising our DCs yet, but what we'll probably do is to just have a pair of low-spec, lower-power physical servers set up as DCs and then virtualise everything else. See what other replies you get. There might be different (or better!) ways of doing it.

Yes - Open Failover Cluster Manager, expand Services & Applications. Right-click your VM and choose Properties. On the Failover tab, there is an option to allow Failback. This will cause the service to fail back to the most preferred owner, which you can set on the General tab.

Have a look at the Folio range (http://www.folio.co.uk/pdf/10409_Folio2.pdf). They're nicely designed so that there's nowhere for the keyboard and mouse cables to get trapped. We've recently bought some and they look very robust, although time will tell. Ours aren't properly set up yet, but as far as I know you can daisy-chain power connections for up to 4 desks in a row from a single mains socket, although you'd need separate network sockets/cables for each one.

How silly all this is and how foolish are those who propagate this deception. The return of Christ has been predicted, unsuccessfully, many times before, by all sorts of cults, cult leaders and sadly also those who claim to be Christians. What makes them think this time will be any different. Have they learned nothing from history? Have they learned nothing from the Word of God Himself? If they actually read their bibles, they would find the truth written so plainly ("No one knows about that day or hour, not even the angels in heaven, nor the Son, but only the Father..... so you also must be ready, because the Son of Man will come at an hour when you do not expect him" Matt. 24:36,44). Perhaps the reason the truth is obscured from them is because they do not know the One who IS the truth (Jesus said "I am the way the truth and the life." John 4:16) All this serves to do is to cloud and obscure the real issue, which is not one of timing, but of readiness. "So you must also be ready". We can have a bit of a laugh at these kind of proclamations, but the REAL truth is more serious. One day Jesus will return to judge the earth as king of kings and Lord of Lords. We do not know when that day will be. Are you ready for it? Those who know Jesus as their Saviour can look forward to some day meeting him as their friend and king. Those who reject him will meet him as their judge. The everlasting life that Jesus brings is free for all who will accept the forgiveness he offers. How will you meet him on that day?

Yes, we've been doing this for a couple of years, although with plain windows 2008 terminal services rather than XenApp. Are we happy with the results? Yes and no. Some benefits: You don't need to worry about deploying large software packages and hotfixes over a wireless network You don't have problems with wireless network congestion when multiple users are trying to login & load roaming profiles over the wireless network at once If a laptop fails or loses its connection or the battery dies, you can re-connect to your session on another laptop, without losing everything. You can use older/cheaper/lower-spec laptops without worrying too much about performance degrading. Great for IT support, we spend very little time dealing with software issues on the clients. However: RDP 5.2/6 performance over wireless isn't great (XenApp might be better). It's noticeably more "laggy" than on ethernet. It's fine for general use, but anything multimedia is completely hopeless. You need to ensure your wireless network is as close to "bullet-proof" as possible. Remoting protocols like RDP or HDX require a continual stream of uninterrupted data, if you think about how they work it's quite different to conventional thick clients. Packet-loss or excessive latency on the wireless network will cause the user experience to be glitchy - laggy response to k/b and mouse inputs, temporary lockups, loss of connection to the session etc. Packet loss will probably be a bigger issue than bandwidth. The user experience is not great because of these issues. Ask our users about their experiences with laptops and the response will not necessarily be particularly positive. Things to consider: How many thin client laptops are your proposing and is your wireless network up to the job? If multimedia performance is important to you then test carefully before deploying. There are much better remoting protocols than RDP 5.2/6, but I would imagine that wireless bandwidth may become an issue. What OS are you going to run on your laptops? There are various options from Linux with ThinStation to the new Windows 7 thin OS. On most of ours, we boot XP and have replaced the explorer.exe shell with mstsc.exe (terminal servies client). There are some policies to prevent unauthorised tweaking. Would we do it again? Don't know. It works and does what it set out to do, but the poor user experience is a problem, so we would need to look at better remoting protocols. So many websites and educational resources now have embedded video/audio/animation and users expect to get decent multimedia performance. At the moment we aren't delivering that. We understand why, but they don't. We started out by saying that it didn't really matter as that wasn't essential, but the fact is that the user experience is poor and the feedback from the user base is not particularly positive. So - have a think about what your requirements are and test carefully.

What about these? We've been looking at RM Ones as well, so would be interesting to know how they compare price-wise.

The shares are missing because either the File Replication Service and/or Netlogon service isn't running. Check in services to see and try starting them. If they don't start, you need to have a look in the event log. I would suggest checking the File Replication Service log first as I think this is where the problem is likely to be. I'm pretty sure if the File Replication Service doesn't start, then you won't see those shares.

We have found that to get it to work with proxy settings at all, you have to click the "Use Internet Explorer Settings" box, even if you don't intend to use Internet Explorer settings. You can still enter the proxy details manually. You should find that clicking "Test connection" will then report success. There is a bug in that when you open the program and click Continue, it will fail to connect if you are using a proxy. We have found that if you open the program, click the Proxy tab and then click straight back onto the Login tab, you can then click Continue and it will connect without any errors. Also check that it has saved the "Use Internet Explorer Settings" tick box, it doesn't always seem to.

As someone else has said, the problem is caused by the way that the session broker and network load balancer work together. When you connect to the farm, the load balancer will connect you to one of the servers. You then have to login for the session broker to know who you are and where to place your session. If it decides to place your session on a different server to the one that network load balancer connected you to, you get a second login prompt. To resolve this, you need to get the client to handle the authentication. For XP clients, you will need to enable Network Level Authentication and you will need SP3 installed with Remote Desktop Client at least v6.1 to do that. To check if Network Level Authentication is enabled, open the remote desktop client, right-click in the title bar and choose About. If it says Network Level Authentication Not Supported, you will need to enable it as follows: - Browse to HKLM\SYSTEM\CurrentControlSet\Control\Lsa - Locate Security Packages and add tspkg to the bottom of the list - Browse to HKLM\System\CurrentControlSet\Control\SecurityProviders - Locate Security Providers and add , credssp.dll at the end - Restart the computer - Now check that Network Level Authentication is enabled as above In the RDP file that you use to connect, make sure you've got the following settings: authentication level:i:0 prompt for credentials:i:0 promptcredentialonce:i:1 enablecredsspsupport:i:1

I don't know if you got this one sorted or not, but if not the first thing to do is browse to h:\rmusers\xxx on the server and see if the users home folders are still shared. If not, try restarting the server service and see if the shares re-appear. I'm a little concerned that your users have simply disappeared from the RMMC. Have you checked that the RMUsers$ share is still present on H:\RMUsers? The H:\RMUsers\Students\Profiles folder should also be shared as RMStudentProfiles and H:\RMUsers\Students\Work as RMStudentWork If you have problems with drives or shares disappearing when the server is restarted, you have to make sure both your targets AND volumes are persistent: 1. Open the Microsoft iScsi initiator and make sure your targets have the "Automatically restore this connection when the system boots" ticked. 2. Check on the Persistent Targets tab and check that your targets are showing on there. 3. Click on the Bound Volumes/Devices tab and ensure your volumes are persistently bound - if not add them - for example H:\ That should resolve any issues with the iScsi targets and volumes not being available when the server service starts and you should find all your users shares listed if you look in Computer Management | Shared Folders or if you do a NET SHARE at the command prompt From your description, it sounds like you have simply expanded your H:\ drive so that it spans a locally attached disk and an iScsi disk? I think you are going to have issues with this. I would never recommend that you span a volume across a local disk and an iScsi disk in that way, you are going to possibly suffer from serious data corruption if the iScsi target was to become disconnected - because all of a sudden half your volume would be gone. It would be better by far to just move the entire contents of H:\ onto the new iScsi volume that you created. It's very simple to do so, and works fine on CC3 (who knows/cares if it's supported by RM?). Briefly, this is how we did it: 1. Setup your iScsi targets and drives (e.g. D,F,G and H are the ones we did) - so these will be visible in Disk Management as for example w,x,y,z 2. In Disk Management, REMOVE the drive letter assignments from the existing volumes (D,F,G and H) 3. Reboot the server (expect errors in the event log after the first boot) 4. Modify the drive letter assignments of the new iScsi volumes to match the old ones (so you've got for example D,F,G and H again) 5. Restore the entire contents of each volume using BackupExec or whatever, I suppose you could also use something like RoboCopy, but BackupExec will also restore quota data as well. 6. Once the restore is complete, enable Quota Management on H: and set the option to deny disk space to users exceeding the quota. Do not tick the Limit Disk usage option. 7. Reboot the server once again and check that drives and shares have appeared as expected and that there are no unexpected errors in the event logs.

As I recall, folder redirection can be really fussy about the permissions on the redirected folder. Do the folders you are redirecting to already exist? Ie does the \\server\staffhome\%username% folder exist, or are you trying to create it when the folder is redirected? If so, you'll need to ensure that users have at least the Create Folders/Write Data permission on the parent folder \\server\staffhome. If the %username% folder does already exist, I seem to recall that the user needs to have at least modify permissions on that folder and also, needs to be the OWNER. In other words, if Administrator is the owner and not the user, then it won't work. What I would recommend is to have a look at the policy settings and try removing the "Move contents of Documents to the new location" and "Grant the user exclusive rights to Documents" options. That's how we have ours set and we don't have any problems. Also, the group policy client will usually log any errors that arise with folder redirection, so look in the Application Event Log on the workstation and see what it's reporting. My guess is you're getting an access denied somewhere.

I think the most important thing is that the Bible itself claims to be infallible. Or to put it another way, the Biblical writers claimed it to be infallible based on their knowledge of God's character. For example, the Bible says that "men spoke from God as they were carried along by the Holy Spirit" and "All scripture is God-breathed and is useful for teaching, rebuking, correcting and training in righteousness" Those two quotes are really saying the same thing - that the Bible was inspired by God, and although it was written down by fallible men, they were working under the inspiration of God, who in his perfect nature simply cannot lie or make mistakes. "God-breathed" is simply a way of saying that God spoke through his Spirit into the hearts of biblical authors - inspiring them to write down the essence of what he intended to make known. This opens up the whole question of Biblical authority. If the claims of the Bible are true and it was written under the influence of a perfect, infallible God, then it means that the Bible must be the ultimate source of authority and the only source of absolute truth. Of course there are other things that are true, but how can we absolutely, I mean absolutely guarantee the truth of anything? If we believe the Bible's claims about itself, and about the character of God, then it isn't a problem for us to say that as God alone is perfect, so therefore must his word be. When we're talking about the Bible being "literal", it's important to clarify exactly what we mean. Within the Bible, there are many different styles of writing - for example historical narrative, prophecy, allegory, poetry etc, and can't all be read literally. Instead, a "plain reading" of the Bible considers the style of writing in the book or passage you're reading. The Book of Genesis, for example, is literal historical narrative, written down thousands of years after the events it describes, the intention of the author being that his audience would read and understand it as a literal historical account of events. How else could this account of creation have been written apart from by God's inspiration, since nobody was around to see it happen. The message of the Bible is as relevant today as it was 2000 or more years ago. It's a message that everyone needs to hear. It tells us about God, about ourselves and how God sees us, about what God has done for us and about what He wants us to do. Accurate? Absolutely. "Here is a trustworty saying that deserves full acceptance - Christ Jesus came into the world to save sinners". That's a well known Bible passage. Can we consider it trustworthy? If we believe that the Bible is the perfect, inerrant word of God then it's a certainty. If we don't consider the Bible to be accurate then how do we decide which parts of it are true and which aren't and how can we be sure of even a saying such as this?