none
Problem with configuring VSeWSS 1.3 CTP w/ VS 2008

    Question

  • Hello - I'm getting the following error while trying to deploy one of the new themes released by Microsoft.

    Error 1 VSeWSS Service Error: Error loading assembly D:\Program Files\Microsoft\TenThemesForSharePoint\TenThemesForSharePoint_March2009\ContosoSiteTheme\ContosoSiteTheme\bin\Debug\ContosoSiteTheme.dll.

    VSeWSS Service Logging Error: Access to the path 'C:\Documents and Settings\Default User\Application Data\Microsoft\VSeWSS 1.3' is denied.

    Logging failed attempting to write to C:\Documents and Settings\Default User\Application Data\Microsoft\VSeWSS 1.3\VSeWSS1.3 service.log. This may occur because the VSeWSS WCF Service does not have local administrator permissions. Please review the release notes. 

    I've read the release notes but I don't seem to understand them.  This is from the release notes:

    VSeWSS 1.3 includes a web service that needs to run as a member of the local Administrators group. The web service is used by the Visual Studio extension to communicate with SharePoint and is restricted to local connections only. As a security precaution the installer does not add the account running the web service to the local Administrators group. You must do it. If you select the default during install the web service is run under the account that SharePoint Central Administration runs as. To do this:

    1) Run Internet Information Services (IIS) Manager to look up the account name
    2) Run Computer Manager to edit the Administrators group and add the account


    I went into IIS, I found the VSeWSS service but I don't know what they mean by look up the account name.  If I go into Properties | Directory Security, I see that the Authentication Methods is set to run in "Integrated Windows authentication." 

    Any help is greatly appreciated.

    Thank you

    Friday, March 20, 2009 11:22 AM

Answers

  • Yet another Update:

    I uninstalled 1.3 and reinstalled 1.2 and both apps deployed ok.  I rebooted the VM.  I decided to take another chance on 1.3.  I uninstalled 1.2 and prepared to install 1.3.  This time, I created an app pool called VSeWSS first.  Then, during the installation of 1.3, I typed in VSeWSS for the app pool to use.  The installation completed normally.  I deployed my workflow and it worked.  So I decicded to deploy the theme and IT WORKED! 

    /Jump For Joy

    I think I'm going to get my VM backed up right now.

    Thank you again for the suggestions.  I'm sure it was a combination of everything above that got me to this point.  I wish I could do it all over on a clean VM to help others that might have these issues. 

    again, thank you very  much!!!

    Tuesday, March 24, 2009 1:50 PM
  • Not only does the account need to be part of the Administrators security group, it also needs to be part of all the security groups listed.

    It also needs to be a member of the Site Collection Administrators Security Group (From the Root Site, go to Settings -> Site Collection Administrators.

    This isn't related to the NTLM issues but may be the cause of some of the other authorization issues.
    Tuesday, March 24, 2009 12:58 PM

All replies

  • Within IIS expand Application Pools and find the VSeWSS application pool. If you selected an existing one you can find out which by clicking properties of the VSeWSS Website and clicking the Home Directory tab.

    Once you identify the correct application pool right click and select properties. The account specified on the identity tab needs to be in the administrators group for the server.

    Posting is provided "AS IS" with no warranties, and confers no rights.
    Monday, March 23, 2009 2:59 PM
  • Hi Michael - thank you for replying.  When I installed 1.3 CTP, it defaulted to use the "SharePoint Central Administration v3" Application Pool.  If I expland that app pool, I can see an entry for VSeWSS.   The Application Pool Identity is "Predfined" as Network Service.   I added this user to the Adminstators group as well as: WSS_ADMIN_WPG, WSS_RESTRICTED_WPG, and WSS_WPG.  Same error.  

    Error 1 VSeWSS Service Error: Error loading assembly D:\Program Files\Microsoft\TenThemesForSharePoint\TenThemesForSharePoint_March2009\ContosoSiteTheme\ContosoSiteTheme\bin\Debug\ContosoSiteTheme.dll.

    VSeWSS Service Logging Error: Access to the path 'C:\Documents and Settings\Default User\Application Data\Microsoft\VSeWSS 1.3' is denied.

    Logging failed attempting to write to C:\Documents and Settings\Default User\Application Data\Microsoft\VSeWSS 1.3\VSeWSS1.3 service.log. This may occur because the VSeWSS WCF Service does not have local administrator permissions. Please review the release notes.  0 0 

    I'm trying to deploy the new themes that were just released.  I uninstalled 1.3 and went back to 1.2 and the deployment of the theme worked fine.  Also, I have a workflow that I can seem to deploy just fine using 1.3 CTP.  So I'm not sure if it's just the themes and 1.3 that is messed up or just me :(

    Setting this up to work shouldn't be this confusing.  I'm working in a VM environment tied to AD accounts.

    I would love to get this up and running. Thank you for the help and any assistance you or others can provide me to get past this problem.

    Thank you.

    UPDATE: Michael, I went and created a folder VSeWSS 1.3 in this folder:

    C:\Documents and Settings\Default User\Application Data\Microsoft

    I'm not sure why it want's to use the Default User instead of my named folder.  It is still updating the log file, VSeWSS1.3.log, in my named user application data folder and NOT the Default User.  So why is it referencing it?  Now the error message shows this:

    Error 1 VSeWSS Service Error: Error loading assembly D:\Program Files\Microsoft\TenThemesForSharePoint\TenThemesForSharePoint_March2009\ContosoSiteTheme\ContosoSiteTheme\bin\Debug\ContosoSiteTheme.dll.

    Log file written to: C:\Documents and Settings\Default User\Application Data\Microsoft\VSeWSS 1.3\VSeWSS1.3 service.log  0 0 

    Crazy!!!

    Monday, March 23, 2009 5:41 PM
  • Did you restart the app pool?
    Posting is provided "AS IS" with no warranties, and confers no rights.
    Monday, March 23, 2009 7:57 PM
  • I had very similar problems, not with that exact error message but just random security issues.

    Try changing the Central Administration v3 Application pool to run as an actual user, this can be local or domain, and needs to be members of all those groups listed.

    I found using the ADMINISTRATOR user to be easiest... whether this is poor security policy or not I'm not sure, but it got everything working!

    I would then perform a full IISRESET and restart VS.
    Tuesday, March 24, 2009 12:07 AM
  • Thanks for the suggestions.  I tried the following with the indicated results.  I don't have access to the admin password but I am part of the adminstrators group.

    Using Local System
    Error 6 VSeWSS Service Error: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

    Log file written to: C:\Documents and Settings\Default User\Application Data\Microsoft\VSeWSS 1.3\VSeWSS1.3 service.log  0 0 

    Local Service
    Error 1 VSeWSS Service Error: Attempted to perform an unauthorized operation.

    Log file written to: C:\Documents and Settings\Default User\Application Data\Microsoft\VSeWSS 1.3\VSeWSS1.3 service.log  0 0 


    Network Service
    Error 6 VSeWSS Service Error: Access denied.

    Log file written to: C:\Documents and Settings\Default User\Application Data\Microsoft\VSeWSS 1.3\VSeWSS1.3 service.log  0 0 


    Using my Id and using a new app pool
    Error 1 The HTTP service located at http://127.0.0.1:1378/SPService.svc is too busy.   0 0 


    Update:
    The admin reset WCF (%Windir%\Microsoft.Net\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe -r) and now the following error message is returned:

    Error 1 The HTTP request is unauthorized with client authentication scheme 'Negotiate'. The authentication header received from the server was 'Negotiate,NTLM'.  0 0 

    But according to this:

    By default, the NTAuthenticationProviders metabase property is not defined when you install IIS 6.0. IIS 6.0 uses the Negotiate, NTLM parameter when the NTAuthenticationProviders metabase property is not defined. Therefore, you do not have to configure IIS to use the Negotiate,NTLM property value unless the default value has been overwritten.

    After running the adsutil.vbs script:
    C:\Inetpub\AdminScripts>cscript adsutil.vbs get w3svc/1/root/NTAuthenticationProviders
    Microsoft (R) Windows Script Host Version 5.6
    Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

    The parameter "NTAuthenticationProviders" is not set at this node.

    So wouldn't this suggest Negotiate,NTLM is in use? 

    Now, what used to deploy doesn't anymore because of the above error. 

    :(

    Tuesday, March 24, 2009 11:57 AM
  • Try: 

    inetpub\AdminScripts>cscript adsutil.vbs set w3svc/NTAuthenticationProviders "Negotiate, NTLM"
    IISReset

    Also, with the same account as the app pool can you write to this folder?
    C:\Documents and Settings\Default User\Application Data\Microsoft\VSeWSS 1.3


    Posting is provided "AS IS" with no warranties, and confers no rights.
    • Proposed as answer by dahiya Friday, June 12, 2009 9:40 PM
    Tuesday, March 24, 2009 12:55 PM
  • Not only does the account need to be part of the Administrators security group, it also needs to be part of all the security groups listed.

    It also needs to be a member of the Site Collection Administrators Security Group (From the Root Site, go to Settings -> Site Collection Administrators.

    This isn't related to the NTLM issues but may be the cause of some of the other authorization issues.
    Tuesday, March 24, 2009 12:58 PM
  • I did that:

    C:\Inetpub\AdminScripts>cscript adsutil.vbs get w3svc/NTAuthenticationProviders
    Microsoft (R) Windows Script Host Version 5.6
    Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

    NTAuthenticationProviders       : (STRING) "Negotiate,NTLM"

    but I still receive the same error.

    Error 1 The HTTP request is unauthorized with client authentication scheme 'Negotiate'. The authentication header received from the server was 'Negotiate,NTLM'.  0 0 

    Everything is running under Network Service because that's what the SharePoint Central Administration v3 pool is running under.  I'm afraid if I change it around much more, I won't be able to run anything.  Now that I can't deploy anything, I might have to start all over with a new environment :(

    Tuesday, March 24, 2009 1:14 PM
  •  I can't believe 1.3 is this difficult to configure.  Nowhere in the readme does it say this.  (Sorry.  I know it's not your fault - I'm just frustrated)  As a developer, not an admin, I should just be able to install this like I did with 1.2. 

    Thank you for all of your help.  This just isn't going to work.  I think the only thing I can do is uninstall 1.3 and put 1.2 back on and run with it.  That is, if it will work now. 

    I wish this was released with all the necessary permissions set during the installation.  It sure would have made it a lot easier on most people.

    Thanks again!!!
    Tuesday, March 24, 2009 1:16 PM
  • Yet another Update:

    I uninstalled 1.3 and reinstalled 1.2 and both apps deployed ok.  I rebooted the VM.  I decided to take another chance on 1.3.  I uninstalled 1.2 and prepared to install 1.3.  This time, I created an app pool called VSeWSS first.  Then, during the installation of 1.3, I typed in VSeWSS for the app pool to use.  The installation completed normally.  I deployed my workflow and it worked.  So I decicded to deploy the theme and IT WORKED! 

    /Jump For Joy

    I think I'm going to get my VM backed up right now.

    Thank you again for the suggestions.  I'm sure it was a combination of everything above that got me to this point.  I wish I could do it all over on a clean VM to help others that might have these issues. 

    again, thank you very  much!!!

    Tuesday, March 24, 2009 1:50 PM
  • Creating a seperate application pool for VSeWSS also worked for me.

    Steps taken:
    1. Installed VSeWSS 1.3 using the Sharepoint Admin (default) as the app pool
    2. Created a "hello world" webpart
    3. Deployed - Error
    4. Read this thread
    5. Uninstalled VSeWSS 1.3
    6. Created a new application pool "VSeWSS" with default settings
    7. Install VSeWSS 1.3 using the app pool "VSeWSS"
    8. Deploy webpart - works!

    Windows 2008, VS2008
    Tuesday, March 31, 2009 1:28 AM
  • Hello,

    I've tried to follow your steps without uninstalling VSeWSS 1.3.

    I created a new application pool "VSeWSS" with default settings.
    In IIS Manager, Web Sites, right click on VSeWSS, Properties, Home Directory tab, on application pool I've selected the new created application pool "VSeWSS" and it worked.

    Thank you.
    • Proposed as answer by dahiya Friday, June 12, 2009 9:41 PM
    Thursday, April 30, 2009 3:24 PM
  • Hi,

    I'm getting following error all the time when trying to deploy a webpart:  "The HTTP service located at http://127.0.0.1:1378/SPService.svc is too busy."

    My environment is w2k3, vs2008 sp1, MOSS 2007 and VSeWSS 1.3.
     
    I have tried several times to install VSeWSS 1.3 under the Central Administration v3 Application pool with port 1378 as well as tried to create specific VSeWSS application pool from installer and tried to create VSeWSS application pool beforehand. Every time webpart deploying results to the error message seen above.
    And I have gone through all the instructions mentioned in this thread this far and ensured those have been set properly. Without any help? Googling the error message gives only one hit, which is this thread....


    Any ideas what's wrong? I need to get forward with this.

    Thanks for advance!

    -------------------------------------------------------------------------------------------------------------------------------------------
    Update on May 14, 2009:

    I got this finally working today.
    I just installed VSeWSS with all the defaults. And then included Network Service to Administrators group on w2k3. Previously I had tried to assign specific windows account (VSeWSS) to application pool as configurable identity. (Right-click Application Pool - Identity tab) The way that seems to work is to use the predefined identity, Network Service (Which nees to be included to Administrators group).

    Br
    • Edited by Roosteri Thursday, May 14, 2009 9:01 AM found solution myself
    Tuesday, May 12, 2009 9:32 AM
  • I am getting below error.

    2009/05/12 17:46:04    Error
    Microsoft.SharePoint.Tools.Utilities.VSeWSSServiceException
    Microsoft.SharePoint.Tools.Utilities.VSeWSSServiceException: VSeWSS Service Error: Assembly H:\My Documents\Technical\MOSS 2007\Working Folder\Source Code\WSSExtensTestProj\bin\Debug\WSSExtensTestProj.dll not found. This may occur because the VSeWSS WCF Service does not have local administrator permissions. Please review the release notes.

    Log file written to: C:\Windows\system32\config\systemprofile\AppData\Roaming\Microsoft\VSeWSS 1.3\VSeWSS1.3 service.log
       at Microsoft.SharePoint.Tools.Utilities.SPProxy.HandleResponse(Response response)
       at Microsoft.SharePoint.Tools.SharePointSolutions.AssemblyFeatureElementDirector.Constract()
       at Microsoft.SharePoint.Tools.SharePointSolutions.AssemblyFeatureDirector.GetFeatureElement(ICollection`1 directors)
       at Microsoft.SharePoint.Tools.SharePointSolutions.AssemblyFeatureDirector.Constract()
       at Microsoft.SharePoint.Tools.SharePointSolutions.AssemblySolutionDirector.ConstractElements()
       at Microsoft.SharePoint.Tools.SharePointSolutions.AssemblySolutionDirector.Constract()
       at Microsoft.SharePoint.Tools.SharePointSolutions.SolutionCreator.CreateCore(ISPProject project, IDirectorCreator creator)
       at Microsoft.SharePoint.Tools.SharePointSolutions.SolutionCreator.CreateForDeploy(ISPProject project)
       at Microsoft.SharePoint.Tools.SharePointSolutions.SolutionDeployer.Deploy()

    Its same as you all got.
    I follwed each and every step as mentioned above. I am still getting this error.

    I am using a
    > Hyper-v VM- Server 2008 64 bit System.
    > Installed Visual Studio 2008 extensions for Windows SharePoint Services 3.0, v1.3 - Mar 2009 CTP from http://www.microsoft.com/DOWNLOADS/details.aspx?familyid=FB9D4B85-DA2A-432E-91FB-D505199C49F6&displaylang=en .
    > I created an application pool and changed the identity to the account which has administrator rights and which also part of the

    o        Administrators

    o        IIS_IUSRS

    o        Users

    o        WSS_ADMIN_WPG

    o        WSS_RESTRICTED_WPG

    o        WSS_WPG

    o        SQLServer2005MSSQLUser$ - Unique on your machine created for SQL Server access

    and then assigned this application pool while installing the extensions.

    I reset the iis and rebooted the system and restarted the visual studio. Same problem exists.

    Please help how to resolve this issues.

    Thanks & Regards,
    Sravan Kasyap K.


    Sravan Kasyap
    Wednesday, May 13, 2009 4:17 PM
  • I was dealing with the same problem and believe I have just resolved it for myself. It seems others in this thread got this working a different way, so I'm presenting this as an alternate possible solution.

    I at first received the error: 

                       " *.dll not found. This may occur because the VSeWSS WCF Service does not have local administrator permissions. Please review the release notes."

    When I configured the VSeWSS App pool to use the local administrator account, I got the error:  

                    "The HTTP service located at http://127.0.0.1:1378/SPService.svc is too busy."

    I then changed the VSeWWS App pool to use "Local System", and was suddenly able to package wsp's again without error

    Note that I am working on the virtual machine upon which our dev SharePoint server is running. Of course, I don't really understand Microsoft technologies all that well yet, so I'll leave the how's and why's of this solution as an excercise for the reader.

    Thanks to everyone for pointing me in the right direction!

    Tuesday, August 4, 2009 2:50 PM
  • Hei guys I also spent 5 hours in this incredible problem.
    Attention the sintax reported above ..."Negotiate, NTLM" for me was terrible because the space, I have used this: 'cscript adsutil.vbs set w3svc/NTAuthenticationProviders Negotiate,NTLM' and all was OK!!!
    Hope can help somebody!
    Tuesday, September 1, 2009 3:26 PM
  • Good Eveing,

    having a similar question/issue:

    in the logfile these entries occur:

    2009/09/05 14:38:28    Error
    Microsoft.SharePoint.Tools.WebNotFoundException: No SharePoint Site exists at the specified URL.
       at Microsoft.SharePoint.Tools.SharePointProxies.SPProxyUtility.GetWeb(String url)
       at Microsoft.SharePoint.Tools.SharePointProxies.SPListCollectionFacade.GetLists(String siteUrl)
       at VSeWSS.Server.Services.SPService.GetListCollectionLists(String siteUrl)

    2009/09/05 14:43:17    Error
    Microsoft.SharePoint.Tools.WebNotFoundException: No SharePoint Site exists at the specified URL.
       at Microsoft.SharePoint.Tools.SharePointProxies.SPProxyUtility.GetWeb(String url)
       at Microsoft.SharePoint.Tools.SharePointProxies.SPListCollectionFacade.GetLists(String siteUrl)
       at VSeWSS.Server.Services.SPService.GetListCollectionLists(String siteUrl)

    2009/09/05 14:45:51    Error
    Microsoft.SharePoint.Tools.WebNotFoundException: No SharePoint Site exists at the specified URL.
       at Microsoft.SharePoint.Tools.SharePointProxies.SPProxyUtility.GetWeb(String url)
       at Microsoft.SharePoint.Tools.SharePointProxies.SPListCollectionFacade.GetLists(String siteUrl)
       at VSeWSS.Server.Services.SPService.GetListCollectionLists(String siteUrl)

    2009/09/05 14:45:52    Information
    URL: http://localhost:8080/

    2009/09/05 14:45:52    Error
    Microsoft.SharePoint.Tools.WebNotFoundException: No SharePoint Site exists at the specified URL.
       at Microsoft.SharePoint.Tools.SharePointProxies.SPProxyUtility.GetWeb(String url)
       at Microsoft.SharePoint.Tools.SharePointProxies.SPWebFacade.GetWeb(String url)
       at VSeWSS.Server.Services.SPService.GetWeb(String url)

    2009/09/05 14:45:57    Error
    Microsoft.SharePoint.Tools.WebNotFoundException: No SharePoint Site exists at the specified URL.
       at Microsoft.SharePoint.Tools.SharePointProxies.SPProxyUtility.GetWeb(String url)
       at Microsoft.SharePoint.Tools.SharePointProxies.SPWebFacade.GetWebHeirarchy(String url)
       at VSeWSS.Server.Services.SPService.GetWebHeirarchy(String url)

    I also get these error messages when I try to open an existing WSS3-site.. The strange: accessing the URL (ad i tried several: http://localhost, http://wss:3333, http://localhost:8080), they all bring me to the site. I also changed the idety for the app pool to my (domain)admin identity, but the problem stays..

    any ideas??
    Saturday, September 5, 2009 7:27 PM
  • I was dealing with the same problem and believe I have just resolved it for myself. It seems others in this thread got this working a different way, so I'm presenting this as an alternate possible solution.

    I at first received the error: 

                       " *.dll not found. This may occur because the VSeWSS WCF Service does not have local administrator permissions. Please review the release notes."

    When I configured the VSeWSS App pool to use the local administrator account, I got the error:  

                    "The HTTP service located at http://127.0.0.1:1378/SPService.svc is too busy."

    I then changed the VSeWWS App pool to use "Local System", and was suddenly able to package wsp's again without error

    Note that I am working on the virtual machine upon which our dev SharePoint server is running. Of course, I don't really understand Microsoft technologies all that well yet, so I'll leave the how's and why's of this solution as an excercise for the reader.

    Thanks to everyone for pointing me in the right direction!


    I had exactly the same issue and using "Local System" for the VSeWSS application pool worked for me as well.
    Tuesday, September 29, 2009 3:42 PM
  • Adding the account as a Site Collection Admin fixed my issue with permission problems.  Don't you wish Microsoft added that to their documentation????

    Monday, October 26, 2009 7:35 PM
  • Hi all,

    I'm using VSeWSS v1.3 March CTP from Microsoft to create sharepoint solution. I met the same error as you, too. And I solved it as below:

    -IIS
    1) Create VSeWSS application pool. Right click on it and choose Properties. In the Identity tab make sure that you see Network Service in the dropdownlist is selected.
    2) Under WebSite node, refer to VSeWSS, right click and choose Properties. In the Home Directory tab, you select application pool is VSeWSS that you have just create above.

    - In the Computer Management, in the Users and Groups, add Network Service into Administrators group

    Restart ISS. It worked OK. Enjoy it!

    Sinh Nguyen
    Nguyen
    Thursday, November 26, 2009 3:55 PM
  • Hi all
    I have the same problem.
    my account on developer machine is domain account and the identity running application pool SharePoint Central Administration v3 is my domain account.

    I change my domain password and the app pooll SharePoint Central Administration v3 was stopped and VSeWSS said: http://127.0.0.1:1378/SPService.svc is too busy.

    I change the identity password SharePoint Central Administration v3 and everithing is OK.
    Wednesday, March 3, 2010 1:26 PM
  • Creating a new application pool and adding Network service to the admin group worked for me.

    I created an application
    I set VSeWSS app to use the new pool

    It worked to resolve http://127.0.0.1:1378/SPService.svc is too busy.

    Ben


    Wednesday, March 17, 2010 5:47 PM
  • One more additional step for me. After reinstall VSeWSS on a new app pool. It still didn't work. I have to restart the the new app pool then everything started to work

     

    cheers

    Thursday, April 29, 2010 4:52 PM
  • Amazing... worked for me too, but not necessary uninstall VSeWSS1.3... just change de AppPool!!

    Wednesday, May 12, 2010 4:58 PM
  • I had the same problem but it wasnt permissions or Port - it was the Default Public URL that was wrong!

    If your on a single server ( or what MS refers to as a Host header site collection - presumably meaning theres a host header binding in IIS for your sharepoint site)  then you cannot use Alternate access mappings - and your Default Public URL MUST be the same as your server name.

    http://mattfox77.blogspot.com/2010/05/vsewss-error-no-sharepoint-site-exists.html

     

    Once I corrected the Default Public URL I was able to deploy with VSeWSS 1.3 in VS 2008 on 64 bit Windows 2008. I was also able to add additional public URLs without breaking VSeWSS

     

    Tuesday, May 25, 2010 3:49 PM
  • I was dealing with the same problem and believe I have just resolved it for myself. It seems others in this thread got this working a different way, so I'm presenting this as an alternate possible solution.

    I at first received the error: 

                       " *.dll not found. This may occur because the VSeWSS WCF Service does not have local administrator permissions. Please review the release notes."

    When I configured the VSeWSS App pool to use the local administrator account, I got the error:  

                    "The HTTP service located at http://127.0.0.1:1378/SPService.svc is too busy."

    I then changed the VSeWWS App pool to use "Local System", and was suddenly able to package wsp's again without error

    Note that I am working on the virtual machine upon which our dev SharePoint server is running. Of course, I don't really understand Microsoft technologies all that well yet, so I'll leave the how's and why's of this solution as an excercise for the reader.

    Thanks to everyone for pointing me in the right direction!


    Yuor post helped me out. Thank you Stephan.
    Wednesday, June 2, 2010 11:12 AM
  • This page was referenced from elswhere as solution to issue that the SharePoint Solution generator when attempting  to create a site definition did not poplate the treeview with any of the sites on that server.  after hard coded site url typed in, it could see the lists on that site.  But attempt to create site resulted in "No SharePoint Site exists at specified URL".  All things to this point checked and are set as specified.  No difference.  So does anyone have any ideas on what will fix this.


    ERJ MCSD MCDBA
    Friday, July 23, 2010 4:02 PM
  • Hi, did you add the account running the VSeWSS application pool to the 'IIS_WPG' group?

    I did this and it fixed my problem!

    Cheers.

    Tuesday, June 21, 2011 2:45 PM
  • don't remember now and no longer on contract using SharePoint so I can't check it.  Nice to know someone is looking into this.  Will email link to those folks still on contract.
    Edward R. Joell MCSD MCDBA
    Tuesday, June 21, 2011 2:55 PM
  • hello,

    i have tried with all options given in this thread to resolve issues , so i uninstall VseWSS 1.3 and installed VseWSS 1.2 and its working well without errors then why should i go for VseWSS 1.3 ;) :) cheers !! :)

    Thanks,


    dipti chhatrapati
    • Proposed as answer by Mahesh Dhinge Thursday, April 5, 2012 6:00 PM
    Thursday, November 17, 2011 8:52 AM
  • Hi,

    I tried all the above options, but nothing worked. Then I followed the above i.e. uninstall VseWSS1.3 and insall VseWSS1.2.

    Steps to perform;

    1. Uninstall VseWSS1.3

    2. Reboot the server / machine

    3. Install VseWSS1.2

    4. Change the Account of SharePoint Central Administration application pool to Network Service

    5. Restart IIS

    6. Deploy the project, it works.

    Thanks

    Mahesh Dhinge


    Thanks Mahesh Dhinge

    Thursday, April 5, 2012 6:03 PM