Surgient Success

 I am attempting to add an additional MSVS Content host to my default pool.  After the server was initially discovered, we had to make changes to the network adaptors.  We had to switch NIC 1 and NIC 2 (as they were originally misconfigured). 

 Now the Surgient Admin Console will not recognize the changes which were made to the MSVS host (email me for screen shot).  I have attempted restarting the Surgient Windows agent on the MSVS host and re-adding the host, and the problem remains.

Has this happened to anyone?  How did you resolve this?

Thank you,
-Matt

 Your best course of action would be to:

1. shut down the agent on the host.

2. go into VCSAdmin and run 'serverdelete hostname' .

3. restart the agent on the host.

This should clear out the nic information in the database and refresh it with the current information.

Changing NICs in host with MSVS installed can be problematic.  This is because Virtual Server creates a virtual network object for each NIC and this usually happens at installation time.  Microsoft changed the behavior either in R2 or R2 SP1 to also discover NICs at startup but it's not perfect.  Did you switch physical network adapter cards or switch cables on a multiple port NIC card? 

The Surgient Agent only reports what MSVS reports through COM.You'll want to confirm MSVS settings under Virtual Networks > Configure >  for each virtual network choose Network Settings and confirm the value for "Network adapter for physical computer".  The configuration screens should not show an error or a message in Red - that indicates a problem.  Also make sure Windows does not show the NIC has disabled under Network Connections.

In the worse case scenario, you would remove of all of the virtual networks under Configure > View all, then delete all of the .vnc files shown in the path under "Network Settings" (above) and either restart Virtual Server or re-install Virtual Server.  Once the Virtual Server network configuration is set up properly the Surgient Agent will report the NICs correctly.

Thank you both. 

I am looking into the MSVS console now and see that the virtual slots have already been pre-allocated (since the Surgient Agent is installed and it was previoulsy pooled, prior to me finding the error.

We had a similar issue to this in the past and I do not recall how we corrected this.  The following rings a bell "In the worse case scenario, you would remove of all of the virtual networks under Configure > View all, then delete all of the .vnc files shown in the path under "Network Settings" (above) and either restart Virtual Server or re-install Virtual Server.  Once the Virtual Server network configuration is set up properly the Surgient Agent will report the NICs correctly".
I am going to attempt this now, from there I will try Charles' suggestion. 

I am going to ensure that MSVS sees the correct NICs first.  if worse comes to worse, we can uninstall and reinstall MSVS from this content host, as it is not currently being used.

I will provide update shortyly.
Thanks
-Matt

Here is what I attempted so far (below).  Attempting to remove the MSVS Content host (HERMIT11) from database, through the VCSAdmin cmd, I receive the following error (below). 

Here are the steps I attempted, with below error in VCSAdmin:

1.)  removed all virtual NICs from the msvs console on content host (Hermit11).
2.)  stopped surgient agent on msvs host.
3.)  stop MSVS virtual server service on content host (Hermit11).
4.)  ran serverdelete Hermit11 in VCSAdmin (with following erro)...

> serverdelete HERMIT11
Surgient.Platform.Security.SecurityException: 00180001 Authentication failed.  P
lease consult log for more information.
   at Surgient.Platform.Services.Internal.SessionServiceImpl.Surgient.Platform.S
ervices.SessionService.Login(Int32 orgId, String accountName, String password)
   at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(
IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInCont
ext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(R
untimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fE
xecuteInContext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMes
sage msg, Int32 methodPtr, Boolean fExecuteInContext)
   at Surgient.Platform.Services.Internal.ServiceProxy.Invoke(IMessage msg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgDa
ta, Int32 type)
   at Surgient.Platform.Services.SessionService.Login(Int32 orgId, String accoun
tName, String passwd)
   at Surgient.Platform.Services.Internal.RemoteSessionServiceImpl.CompleteLogin
(Guid token, String organizationName, String accountName, Byte[] encryptedPasswd
)
   at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(
IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInCont
ext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(R
untimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fE
xecuteInContext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMes
sage msg, Int32 methodPtr, Boolean fExecuteInContext)
   at Surgient.Platform.Services.Internal.ServiceProxy.Invoke(IMessage msg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgDa
ta, Int32 type)
   at Surgient.Platform.Services.RemoteSessionService.CompleteLogin(Guid token,
String organizationName, String accountName, Byte[] encryptedPasswd)
   at Surgient.Platform.Services.DynamicSingletons.RemoteSessionService_Proxy_3.
CompleteLogin(Guid , String , String , Byte[] )
   at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(
IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInCont
ext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(R
untimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fE
xecuteInContext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMes
sage msg, Int32 methodPtr, Boolean fExecuteInContext)

Server stack trace:
   at Surgient.Platform.Services.Internal.SessionServiceImpl.Surgient.Platform.S
ervices.SessionService.Login(Int32 orgId, String accountName, String password)
   at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(
IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInCont
ext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(R
untimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fE
xecuteInContext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMes
sage msg, Int32 methodPtr, Boolean fExecuteInContext)
   at Surgient.Platform.Services.Internal.ServiceProxy.Invoke(IMessage msg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgDa
ta, Int32 type)
   at Surgient.Platform.Services.SessionService.Login(Int32 orgId, String accoun
tName, String passwd)
   at Surgient.Platform.Services.Internal.RemoteSessionServiceImpl.CompleteLogin
(Guid token, String organizationName, String accountName, Byte[] encryptedPasswd
)
   at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(
IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInCont
ext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(R
untimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fE
xecuteInContext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMes
sage msg, Int32 methodPtr, Boolean fExecuteInContext)
   at Surgient.Platform.Services.Internal.ServiceProxy.Invoke(IMessage msg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgDa
ta, Int32 type)
   at Surgient.Platform.Services.RemoteSessionService.CompleteLogin(Guid token,
String organizationName, String accountName, Byte[] encryptedPasswd)
   at Surgient.Platform.Services.DynamicSingletons.RemoteSessionService_Proxy_3.
CompleteLogin(Guid , String , String , Byte[] )
   at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(
IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInCont
ext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(R
untimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fE
xecuteInContext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMes
sage msg, Int32 methodPtr, Boolean fExecuteInContext)

Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage req
Msg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgDa
ta, Int32 type)
   at Surgient.Platform.Services.RemoteSessionService.CompleteLogin(Guid token,
String organizationName, String accountName, Byte[] encryptedPasswd)
   at Surgient.Platform.Services.RemoteLoginHelper.RemoteLogin(String organizati
onName, String accountName, String passwd)
   at Surgient.Platform.Admin.VcsAdmin.EnsureLoggedIn()
   at Surgient.Platform.Admin.VcsAdmin.RunCommand(BaseCommand cmd, StringCollect
ion args)

Thanks,
-Matt

-Additionally, the MSVS Content host (Hermit11) is still seen just the same as an available Content Host when I click in the "add host" section from our default pool.  NIC setting are still being seen as the same, etc on this content host.  During this time, the MSVS service and Surgient service are stopped on HERMIT11.  If I were to attempt to actually add the host, it would come back with an error that it cannot communicate.  So the database still knows about Hermit11, this is the part which I need to clear and start over from, I am just not sure how to do that.

Thanks,
-Matt

You need to authenticate with vcsadmin before you can run the serverdelete command.

 Try invoking vcsadmin as:

vcsadmin -a admin -p <your admin password>

Alternatively, after bringing up the vcsadmin window, you can log in by:

> login admin <your admin password>

 I had thought that this host was not pooled:  

You will also need to de-pool the host from the managment console before you can run serverdelete on it.

I did this before attempting to make any changes to it.

I did the following and was successful.   I since deployed an App config which utilized this MSVS content Host succesfully.

Thank you for both of your help.

1.)  Removed all virtual NICs from the MSVS content console.

2.)  stopped Surgient agent on MSVS content host.

3.)  Uninstall Microsoft Virtual Server (r2) from MSVS Content Host

4.)  Delete all .vnc files from MSVS content host ( found in default location: C:\Documents and Settings\All Users\Documents\Shared Virtual Networks\ )

5.)  Delete pre-allocated slots and virtual server information (in our case, found on MSVS content host’s  F:\ drive.)

6.)  Reboot MSVS content host.

7.)  Launch VCSAdmin from VCS server

8.)  type "login 'username' 'password' “press enter

9.)  run “ serverdelete 'servername'  “

10.)  (On MSVS content host) reinstall Microsoft Virtual server R2.

11.)  Add back original NIC 1 and NIC 2 within MSVS console (matching names to their NICs).

12.)  Restart Surgient windows agent service on MSVS content host.

13.)  Redetect MSVS content host through Surgient mgmt console.

-Matt