locked
Vail Connector Software Fails to Install ( Multiple Machines ) RRS feed

  • Question

  • I initially installed Vail on an older test box, then decided to run it on my primary WHS box. ( I know that is not recommended, but my WHS is just a double-backup of a hardware NAS ) At any rate, everything seems to be working fine except that I cannot install the connector software.  I just get the message "An unexpected error has occurred. To resolve this issue, contact the person responsible for your network."  Is there anyone that could point me in the right direction to some log files?  I think the only relevant difference in the 2 sets of hardware is that the box I'm currently using has 2 Ethernet cards, but the 10/100 on-board card is bios disabled in favor of the PCI Linksys Gigabit card.  Any help will be greatly appreciated. 
    Friday, April 30, 2010 12:59 PM

Answers

  • I finally gave up and re-installed Vail on my server.  As I suspected, all my problems installing the connector were related to the fact that I switched network cards after setting up the server.  When I set the server up this time I kept the onboard network card disabled, and used the Linksys card.  Problem solved.
    • Marked as answer by Tim Tucker Sunday, May 9, 2010 1:40 AM
    Sunday, May 9, 2010 1:40 AM

All replies

  • Is your server visible on your network? Can you ping your server by IP address? Can you ping it by name? If it's configured to obtain an IP address via DHCP, does it show up in your router's DHCP list?
    I'm not on the WHS team, I just post a lot. :)
    Friday, April 30, 2010 1:13 PM
    Moderator
  • Is this the problem in the release notes that say wait "X" number of hours because of the cert time stamp and PST?
    Grey
    Friday, April 30, 2010 1:30 PM
    Moderator
  • Yup server is visible and ping-able.  I've been transferring files to the server since I got it set up late last night.  ( So it's not the 3 hour thing either ) The server is configured for DHCP, but my router is configured for static DHCP, so the server always has the same IP address.
    Friday, April 30, 2010 1:37 PM
  • Hi Tim,

    Can you collect server and client computer logs using the log collector and file a bug please? Since you hit the unexpected error that means that it has fallen through all others so we'd need to look at it.

    For reference, the location of logs are called out in the release notes: %ProgramData%\Microsoft\Windows Server\
    Windows XP: %AllUsersProfile%\Application Data\Microsoft\Windows Server\

    Thanks for trying out Vail!
    /Lennart


    This post is "AS IS" and confers no rights.
    Kind regards /Lennart
    Friday, April 30, 2010 5:26 PM
  • Looks like VAIL was not yet ready to handle non-US regional settings?
    VAIL server started failing after changing regional settings settings. Easely repaired I as I was testing in a virtual machine.

    For the client connector instllation:
    Same problem here for two different XPSP3 machines.
    For one of them this was solved by:

    1. Making sure server and client were both in the same timezone (in my case GMT+1).
    2. (Resetting) regional settings to English (US)

    The other XP still refuses to install the client connector. The installer runs upto connecting to the server. It even partly add's the machine to the server, then fails.
    Logfiles indicate there is a problem with starting the installed "Server Service Provider Registry service" (similar to errors a got on the server). I think this is also somehow cause due to a regional settings problem (not sure). As a result of this client authorisation fails.

    Not sure yet how to fix/work arround this.
    Certainly something to bug on connect.

    - Theo.

     

     

     

     

     


    No home server like Home Server
    Friday, April 30, 2010 8:08 PM
    Moderator
  • I'm also not able to install the Client Connector.

    The error in the ClientDeploy.log

    ClientSetup: UnSupported Server Sku: SkuId=7
    [1636] 100430.194755.4066: ClientSetup: !!!FATAL!!! Unhandled Exception: System.InvalidOperationException: Unrecognized sku to retrieve localized resources.

    I've tried to install on WIN 7 32 and 64bit on a Dell laptop.

    Thanks

    Friday, April 30, 2010 11:59 PM
  • It is my understanding that only en-us is supported in this build.
    I'm not on the WHS team, I just post a lot. :)
    Saturday, May 1, 2010 12:05 AM
    Moderator
  • I'm having a similar issue.

    I installed Vail on an Acer EasyStore, the first half was done by USB then it hung up but was able to finish the rest on my desktop PC. Now I was able to connect my laptop to the server (when it was still in my desktop). But now that I have it back in the EasyStore i can't get my desktop to HTPC to install the connector software. All computers can see it and transfer files but I just can't install the connector software on the other two computers. I was able to get to the web page to download even, but the install gives me the same error "An unexpected error has occurred. To resolve this issue, contact the person responsible for your network."

    Saturday, May 1, 2010 1:13 AM
  • Bigmoo: Can you file a bug with client and server logs please? The release notes call out how and has a link to the log collector.

    Also please include client computer Windows language, any MUI language packs you have installed, do you have any regional settings set differently (although this shouldn't matter, I've had them set differently before), and if you made any changes to the server.

     

    Thanks for trying out Vail.


    This post is "AS IS" and confers no rights.
    Kind regards /Lennart
    Saturday, May 1, 2010 3:23 AM
  • Hi Theo,

    Can you please file a bug with server logs and what happened when you changed the regional settings on the server?

    For the other issue, are you seeing something like " the Net.Tcp Port Sharing Service failed to start" in the logs?

    The time zone shouldn't matter but we do have the situation where it may change the clock so that the server cert becomes invalid for up to one day.

    Thanks for trying out Vail and thank you for being active with feedback!


    This post is "AS IS" and confers no rights.
    Kind regards /Lennart
    Saturday, May 1, 2010 3:32 AM
  • Can you please file a bug with server logs and what happened when you changed the regional settings on the server?

    For the other issue, are you seeing something like " the Net.Tcp Port Sharing Service failed to start" in the logs?

    The time zone shouldn't matter but we do have the situation where it may change the clock so that the server cert becomes invalid for up to one day.

    Hi Lennart,
    Will investigate this a bit further in the comming days before bugging this to connect. Need some more details as the second XP client still has problems even with en-us regional settings. Apparently on this client there is some other problem that prohits a succesfull client install.
    As far as I could trace the problem for the first client, the ""Server Service Provider Registry service" - and as a result of this - depending provider services (installed by the connector) can not start.

    And you are probably right; time zone does not matter as long as the local times on server and client are in sync (i.e same zone + local time).

    - Theo.

     


    No home server like Home Server
    Saturday, May 1, 2010 10:51 AM
    Moderator
  • I am also in a similar situation.  I used Microsofts Network Monitor to get a trace of whats going on and I think it showed why the connector install dosen't work for me.  My DNS server is part of cox.net and I don't have one on my local network.  While SERVER may be visible from my Win7 client it is not known by my DNS server.  When I run the connector install it can't locate SERVER using DNS so I put in SERVERs IP address and the install continues.  I see lots of traffic to and from SERVER.  After I'm asked to provide the password (which I do) I see a DNS lookup for server..cox.net which the Cox DNS server dosen't know about, further IPV6 attempts to find the server and then I get the error message.  The code that handles the login (password) apparently dosen't know that the IP address is being used and not the server name (SERVER) and gives up.
    Sunday, May 2, 2010 7:15 PM
  • OK thanks, this is starting to make sense now.

    It sounds like cox.net is employing DNS proxy like OpenDNS or some other supplier of these services. We have a bug tracking the need to switch to always use IP address when programmatically accessing the server during the Connect process.

    A workaround without this change would be to edit the HOSTS file of the client. Olaf has a long post for the original version of Windows Home Server here: http://social.microsoft.com/Forums/en/whsfaq/thread/15a9e657-54a3-453f-b0e7-1efa59b7feea

    Let us know if this helps.


    This post is "AS IS" and confers no rights.
    Kind regards /Lennart
    Sunday, May 2, 2010 9:42 PM
  • I was hoping that what laterdaze was running into was the same problem I'm having, but alas it was not the case.  I added DNS entries to my router for my WHS box. ( even though it was already accessible by name ) I tried the connector install again and got the same error.  I downloaded the MS network monitor and tried the install again.  Unfortunately for me the trace looks good, so I guess I'll have to wait and see if the bug report I filed turns up anything. 
    Sunday, May 2, 2010 10:15 PM
  • I modified my hosts file (c:\Windows\system32\drivers\etc\hosts) by uncommenting (delete the #) the IPV4 and IPV6 localhosts lines and adding the IP address of my WHS and it looks like this:

     127.0.0.1        localhost
     ::1                 localhost
     192.168.0.198 server

    Now the connector install works properly and I'm using the Dashboard on the client do a manual backup right now.  To get the new hosts file info into play you must restart the DNS client.  In Windows 7 that would mean drilling down Control Panel - Administrative tools - Component Services - Services - right click on DNS Client and select stop then again and select start.

    Monday, May 3, 2010 2:31 AM
  • Once I figured out that I had to put my laptop in Safe Mode Command Prompt to edit the "hosts" file as laterdaze explained in his thread, I got everything to work perfectly also!

    Thanks for the info and now I'm a bit further along with my beta testing.

    Has anyone documented this into the Vail bug database??

    Monday, May 3, 2010 9:10 PM
  • Great to hear, thank you.

    We have planned feature work around this already and it is in fact being checked in this week so you don't need to bug it. We should have this sorted out so that you do not need to do this the next time.

     


    This post is "AS IS" and confers no rights.
    Kind regards /Lennart
    Tuesday, May 4, 2010 12:42 AM
  • Glad to hear that someone got it working.  Unfortunately for me my bug report is still open, and none of the suggestions people have made here have resolved my issue.  I am fairly sure it is something beyond a networking issue that is causing my connector installs to fail, I just can't figure out what "it" is.
    Wednesday, May 5, 2010 12:50 AM
  • I’ve seen some random networking stack corruptions on the clients before that caused this, can you dump out the following commands from your client?
    - ipconfig /all
    - ping <servername>
    - ping –a <serverIP>
    - tracert <servername>
    - route print
     
    And from your server
    - ipconfig /all
    - ping <clientname>
    - ping –a <clientIP>
    - tracert <clientname>
    - route print
     
    Also, can you confirm you didn’t change any windows firewall settings on the server? and file and print is enabled on both the client and the server?
     
    I can’t say we’ll know for sure (as the stack corruptions sometimes don’t show their face here), but it might provide some insight.
     
    Thanks Tim!
       Sean
     
    This post is "AS IS" and confers no rights.
     
    "Tim Tucker" wrote in message news:17330a1f-b803-4aef-97e6-81deeafe9880...
    Glad to hear that someone got it working.  Unfortunately for me my bug report is still open, and none of the suggestions people have made here have resolved my issue.  I am fairly sure it is something beyond a networking issue that is causing my connector installs to fail, I just can't figure out what "it" is.
    Wednesday, May 5, 2010 1:40 AM
    Moderator
  • If I run all that and zip it up and attach it to my bug report as "Microsoft only" will that work for you? I think I mentioned this earlier, but I've tried like 4 different client machines with the same result, so I doubt they are all corrupted.

    EDIT:  I ran all the commands and attached the output to my bug report.  The bug ID is 556327.  

    Wednesday, May 5, 2010 2:24 AM
  • Hello Tim,

    We've received the bug. I see a couple of differnet issues in the logs, not sure which one is the root cause yet. I see some timeouts and then an MSI exception around the admin creds passed in. The latter one doesn't display any partial password in the logs so I don't think it is a password we don't parse correctly. We'll look some more at this.

    Stay tuned and thanks for trying out Vail.


    This post is "AS IS" and confers no rights.
    Kind regards /Lennart
    Wednesday, May 5, 2010 3:58 AM
  • FYI The connector install process never gets to the point of asking me for the server password. TT
    Wednesday, May 5, 2010 4:27 AM
  • Just an observation, this appears to be similar to the bug submission I have made, Bug ID 556481. Removing the Vail connecter and trying to re install fails with  "An unexpected error has occurred. To resolve this issue, contact the person responsible for your network.". While not a solution or work around, the only way I was able to re-attach was to reload the server.
    Wednesday, May 5, 2010 9:30 AM
  • I read your bug report, and I agree it seems similar.  I'm not sure it's really the same problem because I've tried installing the connector from several different machines ( both real H/W and Virtual ) and have had no success with any of them.  Yours seems to be a case of the uninstaller not cleaning up the system properly, therefore a re-install of the connector fails.  I can't even get the connector to install on a completely clean install of windows. ( client side )  I don't have a problem re-installing Vail since all my data is backed up on a hardware NAS, but I want to give the client deployment team some time to dig through the logs I submitted and see if they can come up with a solution before I burn everything down and start fresh.  At any rate, thanks for the input.
    Wednesday, May 5, 2010 10:01 AM
  • Same problem here  I cannot add the clients to my home server, even after installing a brand new windows with enghlish us settings and location. I've tried both Windows 7 x32 and x64, windows Xp and none off the pc's get connected after putting in the server password.I've used virtual and real hardware as well. Hoping for a solution shortly. I' ve been using WHS for about 2 years and I must say It has saved me more then ones.
    Wednesday, May 5, 2010 7:30 PM
  • Hi Tim,

    Looking some more in the MSI logs we suspect that it may be the known issue around the server password containing a space? We're looking to fix this and we have a bug on this from another thread here.

    Does this match what you are seeing and if yes could you change the server password and let us know if you can then connect clients? You'd need to do it form naitve Windows UI.


    This post is "AS IS" and confers no rights.
    Kind regards /Lennart
    Wednesday, May 5, 2010 10:36 PM
  • Sadly neither my server password, nor any of my client passwords have a space in them.  TT
    Wednesday, May 5, 2010 11:24 PM
  • OK, can you do me a favour and look in the clientcore.msi log file on one of your computers and look for this line: "Info 1639.Invalid command line argument. Consult the Windows Installer SDK for detailed command line help." See if you recognise something under that line (we're fixing this), what comes before that string may be a special character of some sort?


    This post is "AS IS" and confers no rights.
    Kind regards /Lennart
    Thursday, May 6, 2010 3:13 AM
  • I'll check this when I get home from the office.  Darn work getting in the way of my testing...
    Thursday, May 6, 2010 5:15 PM
  • I am getting an issue also. It might be the same as the other ones but not sure. The connector software crash right at the point of it wanting to install .net framework 3.5.1( which windows 7 has). So disable .net framework and enabled it, with still the same issue. I then ran the .net framework verification tool and everything checks out. And yes all the time zones are right. So here is a little something that I found in the error logs that might be of help to find the root issue here. Oh and also I ran a  repair install on Windows 7 x64 just for the fun of it and still get the same error!!!!

     

    Faulting application name: ClientDeploy.exe, version: 6.1.7495.0, time stamp: 0x4bc7a10c

    Faulting module name: KERNELBASE.dll, version: 6.1.7600.16385, time stamp: 0x4a5bdfe0

    Exception code: 0xc000041d

    Fault offset: 0x000000000000aa7d

    Faulting process id: 0x137c

    Faulting application start time: 0x01caed512b8a783f

    Faulting application path: C:\Program Files (x86)\Windows Server\Client Deployment Files\ClientDeploy.exe

    Faulting module path: C:\Windows\system32\KERNELBASE.dll

    Report Id: 6b6c116b-5944-11df-8a5d-0019d1ff82ec

    Any help would be awesome as I have googled, and binged so much at well............ 

     

     

    Thanks again

     

    Jeremiah

    Thursday, May 6, 2010 7:30 PM
  • Can you please give me the specific location of the log file you mentioned?  I can't seem to locate it.  TT
    Friday, May 7, 2010 6:46 AM
  • Tim,

    The logs are located in C:\ProgramData\Microsoft\Windows Server\Logs\ for Vista and Windows 7.  If you are running XP you can find the logs under C:\Documents and Settings\All Users\Application Data\Microsoft\Windows Server\Logs\.


    Robert Dhaene [MSFT]

    Post is "AS IS" and confers no rights.

    Friday, May 7, 2010 3:44 PM
  • I looked for the file you mentioned on all my client machines and all I got was an Error 404 File Not Found.  I don't think the connector install process is making it far enough to write that log file.  I'm leaning toward just doing a complete re-install of Vail later today, or perhaps tomorrow.  TT
    Saturday, May 8, 2010 11:13 AM
  • I finally gave up and re-installed Vail on my server.  As I suspected, all my problems installing the connector were related to the fact that I switched network cards after setting up the server.  When I set the server up this time I kept the onboard network card disabled, and used the Linksys card.  Problem solved.
    • Marked as answer by Tim Tucker Sunday, May 9, 2010 1:40 AM
    Sunday, May 9, 2010 1:40 AM
  • I had the failure to connect issue on my Win 7 machine.

    My logs showed that Net.Tcp Port Sharing service failure was where the installation went astray.   In services, the service was failing to start as it expected the file to be in folder version v4.0.21006 but it was in a later version v4.0.30319.  As a workaround I recreated the older version folder and put both the exe and config files for smsvchost. (c:\windows\microsoft.net\framework64\)   Connector was than successfully installed and I am off to fix other issues. 

    I assume that the services problem is a Win 7 or Windows update issue rather than a Vail issue.   Since Lennart mentioned this service in his post I assume he knows the answer to why the service file location was not correctly updated?

    Jim

     

    Wednesday, May 12, 2010 7:46 PM
  • Thanks Tim,

    The logs doesn't complain about any network or IP issues, did you use the same password again and does it have any special characters in it?
    I'll close the bug as no repro for now, we can always re-open it.


    This post is "AS IS" and confers no rights.
    Kind regards /Lennart
    Thursday, May 13, 2010 12:38 AM
  • This is very interesting Jim, thank you.

    Can you please file a bug and upload the client-side bugs using the log collector? Please include what .NET Framework versions you have intalled.

    As an aside, the port sharing service is a Windows server that we enable, we have a dependency on it starting in a timely fashion and we may not need to have that dependency during client deployment, we're looking into that.


    This post is "AS IS" and confers no rights.
    Kind regards /Lennart
    Thursday, May 13, 2010 12:43 AM
  • Same server password, no special characters.
    Saturday, May 15, 2010 12:17 AM
  • On my router I had my domain name filled in. So my ipconfig had "Connection-specific DNS Suffix" set.  So when I pinged my server, it resolved to server.mydomain.com, which resulted in my outside IP address not the internal IP address of the server. Removing the domain name from the router setup, and doing a release and renew, removed the suffix. then the name resolved correctly. After doing that the connect software worked correctly.  Thanks for the hint laterdaze, sean and Tim!
    • Proposed as answer by Chuck Lusin Thursday, May 27, 2010 9:47 AM
    Thursday, May 27, 2010 9:46 AM
  • Purely to add more voices to the discussion.

    I just tried to connect a windows XP machine to the windows home server and gained exactly the same problem described in this thread.

    As stated by others I can confirm that although the connector software tried to find my home server it failed and I had to type in the IP address. Once this had been done it went through the next couple of steps and asked for the password. After entering the password I was told that the server had experienced an unexpected error.

    I changed my hosts file like suggested in this thread and everything works fine now. The connector software is up and running and i'm testing my first backup.

    Thanks for the advice,

    Alex

    Wednesday, June 2, 2010 8:56 AM
  • ...
    I changed my hosts file like suggested in this thread 
    ...

    This points to a name resolution issue. Could you file a bug on Connect about this?
    I'm not on the WHS team, I just post a lot. :)
    Wednesday, June 2, 2010 9:36 AM
    Moderator
  • Added to the following bug report

    https://connect.microsoft.com/WindowsHomeServer/feedback/details/560934/unexpected-error-installing-connector-software#tabs

    Wednesday, June 2, 2010 10:40 AM
  • Purely to add more voices to the discussion.

    the connector software tried to find my home server it failed and I had to type in the IP address. Once this had been done it went through the next couple of steps and asked for the password. After entering the password I was told that the server had experienced an unexpected error.

    Thanks for the advice,

    Alex

    I have this same problem and do not seem to be able to fix by any of the above mentions solutions. If I type in an incorrect password it tells me so,  but stll gives me a password hint that has been deleted from the vail server when I created a new admin password in an attempt to fix this problem.

    Any help would be appreciated

    Kellog001

    Wednesday, June 9, 2010 12:33 AM
  • I found the problem, after looking through other peoples problems.

     I had changed the workgroup to that used in my local LAN  network. After reloading Vail and just the default workgroup " WORKGROUP"  connect software worked OK

    Wednesday, June 9, 2010 6:19 AM
  • Boy, I'm pulling my hair out getting this connector software to work.  Installed WHS Vail and have a Windows 7 client machine.  I downloaded connector software (in the form of an iso).  Running that on my client, all I get is a message that it cannot connect.  I tried modifying hosts files; lmhosts files; and everything else described above, including completely reinstalling WHS.  Nothing seems to work.  I ran the connect troubleshooter software, although don't see an obvious way to attach the resulting log to this post.

     

    I tried installing the connector software by typing http://<servername>/connect, as I saw recommended somewhere, and that does not work.

     

    I'm thinking it might be some dns issue, but can't figure it out.  If I issue an nslookup command on my client, followed by my server name, it says "Server: Unknown" and the address it lists is my gateway IP address.  I would have hoped it would actually list the correct IP address, given that it is in my hosts file.  But, I'm no expert with this stuff.  So, obviously there is something I don't understand. 

     

    I use comcast as my ISP.  I can't help but wonder if a comcast dns suffix is somehow the problem.  I.e. if I issue a ipconfig /all command, it does show a comcast dns suffix and a comcast "connection specific dns suffix."  Definitely appreciate any thoughts.

    Friday, June 25, 2010 5:53 AM
  •  

     

    I spent 2 days trying to solve the installation of client computer problem, including reinstalling Vail server software twice & have now been successful in getting everything working as expected ie setting up remote access, getting a test notebook connected to the server & backing it up successfully, accessing the server from a secure (https://) website using homeserver.com.

    None of this was possible using DHCP.  I set the server NIC  AND my test notebook to  static IP addresses (server 192.168.1.201 & notebook 192.168.1.103 - my router DHCP IP addresses stop at 192.168.1.100) & was able to accomplish all above.

    As a test, I reset my notebook back to DHCP & was unable to connect from my secure remote server, wake up notebook on Vail (sleeping - offline)), launchpad run from my notebook reported an incorect username or password, Vail server reported connection problems with my router, Dashboard reported an unknown error.

    Resetting the notebook to static IP address & all problems disappeared!!!

    Friday, June 25, 2010 9:50 AM
  • To be honest it sounds like either you have a different subnet configuration when using DHCP vs. static IP, or your router's interfering somehow.

    More information would be useful. Could you file a bug on Connect? Include logs from server and client, collected using the vail log collector tool. Ideally, logs collected while configured for DHCP and static IP addressing would be best. Also include information about your network configuration/hardware, such as router model/firmware, etc.


    I'm not on the WHS team, I just post a lot. :)
    Saturday, June 26, 2010 1:58 PM
    Moderator
  • I have a similar bug to report.  At first, the client connector could not find the server at all.  It would bring up the dialog asking me to type in the NETBIOS name or IP.  Typing the name did nothing; it just prompted again.  Typing the IP address gave "An unexpected error has occurred. To resolve this issue, contact the person responsible for your network."

    I noticed that 'ping [hostname]' from the client did not work, so I added the server to my hosts file.  Unfortunately, all this did was make the connector fail automatically -- that is, after launching, it went to the same error message w/o prompting me.

    Seeing the various posts about DHCP fragility, I looked in my router settings and found the discrepancy.  As expected, the router was assigning my H340 a static IP lease based on its MAC address.  However, this configuration included not only the desired IP but a host name -- the old name I'd given to WHS v1.  (I was using the hostname 'Vail' in the new installation to avoid confusion).  So when I looked in the actual DHCP connection table, I saw the H340 listed twice: once with the old name + the static IP, and once with the new name + some other random IP in the DHCP server's auto-assignment range.  I deleted the manual DHCP entry, canceled the IP leases, commented out my changes to the hosts file, and rebooted the H340.  Sure enough, the client connector worked on the first try.

    I'll open a bug with the before/after logs to make sure MS handles cases like this correctly.

    Monday, July 5, 2010 7:16 PM
  • BTW, things that didn't appear to matter:

    1) Using a different NIC during installation vs client connect.  I installed Vail inside VMWare, manually added the driver for my H340's Marvel NIC, then stuck the drive in the H340.  After (literally) months of trying to use the officially supported WHSv1 restore mechanism on the H340, this terrible hack worked on the first try!  I was worried that changing NICs might be blocking the client connector, as reported by Tim Tucker, but it didn't seem to matter once I got DHCP sorted out.

    2) The time zone bug.  I put my client machine in PST, but I forgot to change the H340.  Nevertheless, after the first time the client connector failed, I was able to RDP into the H340 (via its static IP) and change the time zone.  While it didn't help immediately, thanks to DHCP, it didn't appear to be hurting connectivity either.

    Monday, July 5, 2010 7:34 PM
  • Based on your description, this is a router or network configuration issue, not a Windows Home Server or Vail issue. I.e. Vail shouldn't have to handle it...
    I'm not on the WHS team, I just post a lot. :)
    Tuesday, July 6, 2010 1:26 PM
    Moderator